Network intrusion detection system and method

Abstract

The application relates to the technical field of digital information transmission, and particularly discloses a network intrusion detection system and method, which comprises an original data packet analysis module, a packet record acquisition module with a state, a serial number checking module, an encrypted protocol checking module and a decision result output module, solves the problems that the traditional detection has the disadvantages of lacking the ability to detect unknown attacks, being unable to identify zero-day attacks or known attacks after deformation, being in a predicament of processing encrypted traffic, more than 80% of network traffic being encrypted, traditional deep packet detection methods being invalid, and only analyzing metadata resulting in a large amount of key information for detection being lost.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, specifically to a network intrusion detection system and method. Background Technology

[0002] The core driving force behind research on network intrusion detection methods stems from the dynamic interplay between the continuous evolution of network security threats and defense technologies. As network attack methods constantly escalate, traditional detection methods are increasingly proving inadequate, forcing the research field to explore more effective and intelligent solutions.

[0003] Currently, research on network intrusion detection still has some shortcomings, specifically in the ability to detect unknown attacks, the inability to identify zero-day attacks or known attacks that have been modified; and the difficulty in handling encrypted traffic, as more than 80% of network traffic is encrypted, rendering traditional deep packet inspection methods ineffective, while analyzing only metadata would result in the loss of a large amount of critical information that could be used for detection. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a network intrusion detection system and method that can effectively solve the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The first aspect of the present invention provides a network intrusion detection system, comprising: The raw data packet parsing module is used to perform normalization processing on the raw data packet to generate a normalized quintuple and construct a fixed-length binary string as the stream key, extract the initial sequence number, and output the keyed packet.

[0006] The stateful packet record retrieval module is used to query the hash index table based on keyed packets, using the stream key in the keyed packet as the index, to obtain stateful packet records.

[0007] The sequence number verification module is used to verify the sequence number based on the status of the packet record and the transmission protocol type, and output the verified packet record.

[0008] The encryption protocol inspection module is used to determine whether the verified packet record is an encryption protocol carrier. If the verified packet record is an encryption protocol carrier, the encryption protocol inspection is performed and the encrypted verified packet record is output. If the verified packet record is not an encryption protocol carrier, the verified packet record is directly output as an encrypted verified packet record.

[0009] The adjudication result output module is used to perform one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection based on the encrypted and verified packet records, and output the final adjudication result record.

[0010] A second aspect of the present invention provides a network intrusion detection method, comprising the following steps: Based on the original data packet, perform normalization processing to generate a canonical quintuple and construct a fixed-length binary string as the stream key. Extract the initial sequence number and output the keyed packet.

[0011] Based on keyed packets, the hash index table is queried using the stream key in the keyed packet as an index to obtain the packet record with state.

[0012] Based on the stateful packet records and the transmission protocol type, sequence number verification is performed, and verified packet records are output.

[0013] For a verified packet record, determine whether the verified packet record is an encrypted protocol bearer. If the verified packet record is an encrypted protocol bearer, perform an encryption protocol check and output the encrypted verified packet record. If the verified packet record is not an encrypted protocol bearer, directly output the verified packet record as the encrypted verified packet record.

[0014] Based on the encrypted and verified packet records, one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection are performed, and the final decision result record is output.

[0015] Compared with the prior art, the embodiments of the present invention have at least the following advantages or beneficial effects: (1) This invention provides a network intrusion detection system and method. The original data packet parsing module and the flow state management module cooperate to completely get rid of the constraints of session timeout duration by using the standard five-tuple flow key and the execution memory pressure eviction mechanism. This ensures that the cross-time period payload packets of slow attacks can always be associated, which not only guarantees the integrity of detection but also eliminates the risk of memory overflow. The sequence number verification module starts from the transport layer protocol standard and replaces the traditional signature matching with deterministic violation judgment such as the acknowledgment number leading. Zero-day attacks can be identified without relying on attack characteristics.

[0016] (2) This invention performs format and range legality verification only on the plaintext fixed fields of the transport layer security protocol record header, which can efficiently identify abnormal traffic without decrypting the payload. It adapts to the real environment where encrypted traffic accounts for a high proportion, implements hierarchical alarms, and distinguishes the sequence number gap caused by retransmission of compliant networks from real attack behavior, thus greatly reducing the false alarm rate. Attached Figure Description

[0017] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the system module connections of the present invention.

[0019] Figure 2 This is a schematic diagram of the method steps of the present invention.

[0020] Figure 3 This invention provides a flowchart for querying a hash index table using the stream key in a keyed packet as an index to obtain a stateful packet record. Detailed Implementation

[0021] 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 invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0022] Reference Figure 1 As shown, the first aspect of the present invention provides a network intrusion detection system, including: a raw data packet parsing module, a stateful packet record acquisition module, a sequence number verification module, an encryption protocol checking module, and an adjudication result output module.

[0023] The raw data packet parsing module is used to perform normalization processing on the raw data packet to generate a normalized quintuple and construct a fixed-length binary string as the stream key, extract the initial sequence number, and output the keyed packet.

[0024] Based on the original data packet, extract the source Internet Protocol address, destination Internet Protocol address, source port number, destination port number, and transport protocol type, denoted as the original 5-tuple. The transport protocol type includes Transmission Control Protocol or User Datagram Protocol. Normalize the original 5-tuple to obtain the normalized 5-tuple.

[0025] The specific process of normalizing the original quintuple to obtain the canonical quintuple is as follows: Compare the values ​​of the source Internet Protocol address and the destination Internet Protocol address (for Internet Protocol version 4, compare as 32-bit unsigned integers; for Internet Protocol version 6, compare as 128-bit segments, comparing four groups of 32-bit segments in sequence), and take the smaller value as the canonical source Internet Protocol address and the larger value as the canonical destination Internet Protocol address.

[0026] If the Internet Protocol addresses are equal, the source port number and the destination port number are compared, and the smaller value is taken as the canonical source port number, and the larger value is taken as the canonical destination port number.

[0027] The transport protocol type remains unchanged, generating a canonical 5-tuple, including the canonical source Internet Protocol address, the canonical destination Internet Protocol address, the canonical source port number, the canonical destination port number, and the transport protocol type.

[0028] This allows the same network session (bidirectional communication) to generate the exact same stream key regardless of the direction from which data packets come, thus mapping to the same ledger in the hash table.

[0029] Record the orientation of the original quintuple relative to the canonical quintuple. If the original source Internet Protocol address is equal to the canonical source Internet Protocol address and the original source port number is equal to the canonical source port number, then the original direction is from direction A to direction B. Otherwise, the original direction is from direction B to direction A. A is the canonical source and B is the canonical destination.

[0030] The canonical quintuple is concatenated into a fixed-length binary string according to network byte order, denoted as the stream key of the hash index operation. For Internet Protocol version 4, the concatenation length is four bytes plus four bytes plus two bytes plus two bytes plus one byte, totaling thirteen bytes; for Internet Protocol version 6, the concatenation length is sixteen bytes plus sixteen bytes plus two bytes plus two bytes plus one byte, totaling thirty-seven bytes.

[0031] Check the synchronization flag in the Transmission Control Protocol header. If the synchronization flag is set (value is 1), read the 32-bit initial sequence number field from the Transmission Control Protocol header. If the synchronization flag is not set (value is zero), set the initial sequence number field to zero.

[0032] Output the stream key, the original direction of the original quintuple relative to the canonical quintuple, and the initial sequence number field as a keyed packet.

[0033] In one specific embodiment, deterministic normalization mapping maps data packets arriving from any direction to a unique fixed-length flow key, ensuring that bidirectional traffic within the same network session always hits the same state entry in the hash table. This completely resolves the session splitting problem caused by different incoming and outgoing keys in traditional flow aggregation. The module generates canonical 5-tuples by sorting by numerical value (IP first, port second) and records the original direction to preserve the semantics of the attack source, enabling subsequent detection to maintain consistent accounting without losing flow direction information. The flow key uses a fixed byte length, ensuring the efficiency and predictability of hash indexing operations. The initial sequence number is extracted only from the synchronous packet context, and zeroed out of synchronous packets, avoiding the risks of circular dependencies and timing inconsistencies caused by relying on external caches, ensuring that the parsing logic is self-contained and unambiguous. This design provides a unified, clean, and unambiguous input foundation for subsequent flow state management, sequence number verification, and symmetry adjudication, significantly reducing inter-module coupling and system complexity.

[0034] The stateful packet record retrieval module is used to query the hash index table based on keyed packets, using the stream key in the keyed packet as an index, to obtain stateful packet records.

[0035] like Figure 3As shown, a hash index table in memory and a block storage area in a non-volatile storage device (a solid-state drive with a Fast Peripheral Component Interconnect Standard interface) are maintained. Each entry in the hash index table contains the following fields: stream key (a canonical 5-tuple binary string), pointer to the stream state block in memory, offset pointer to the solid-state drive storage location, and last arrived packet count (a monotonically increasing global packet sequence number value).

[0036] Definition of flow state block structure in memory: Source-to-destination statistics field: Total number of packets received (64-bit unsigned integer), Total number of bytes received (64-bit unsigned integer), First packet arrival timestamp in the source-to-destination direction (64-bit, taken from the operating system hardware clock), Last packet arrival timestamp in the source-to-destination direction (64-bit), Initial sequence number in the source-to-destination direction (32-bit, zero if not recorded), Protocol phase marker bitmap (32 bytes, each bit has a predefined fixed meaning: the zeroth bit indicates that the synchronization flag for direction A has been received, the first bit indicates that the synchronization acknowledgment flag for direction B has been received, the second bit indicates that the end flag for direction A has been received, the third bit indicates that the end flag for direction B has been received, and the remaining bits are reserved).

[0037] Statistical domain from standardization destination to standardization source: Field layout is consistent with that from standardization source to standardization destination.

[0038] Global field: Stream establishment timestamp (8 bytes), global most recent update timestamp (8 bytes) (updated when a packet arrives in any direction). To ensure access efficiency, the timestamp field in the global field is aligned to 8 bytes.

[0039] The total number of received packets (8 bytes) plus the total number of received bytes (8 bytes) plus the arrival timestamp of the first packet (8 bytes) plus the arrival timestamp of the last packet (8 bytes) plus the initial sequence number (4 bytes) plus the protocol stage marker bitmap (32 bytes) is a total of 68 bytes. Therefore, both the direction A statistics field and the direction B statistics field are set to a fixed length of 68 bytes.

[0040] Use the stream key in the keyed packet as the index to query the hash index table; Case 1: If the stream key is hit and the memory pointer is not null, based on the original direction indication in the keyed packet, update the statistics field of the corresponding direction in the stream state block, add the current packet payload length to the total number of bytes received in the current direction, increment the total number of packets received in the current direction by one, update the arrival timestamp of the last packet in the current direction to the current time, and update the global most recent update timestamp to the current time. If the current packet is a synchronization packet and the initial sequence number is not zero, store the initial sequence number in the statistics field of the corresponding direction, and set the corresponding bit in the protocol phase flag bitmap (set the zeroth bit if the original direction is from the canonical source to the canonical destination; set the first bit if the original direction is from the canonical destination to the canonical source and the transmission control protocol header sets the acknowledgment flag; if the original direction is from the canonical destination to the canonical source and only the synchronization flag is set without setting the acknowledgment flag, then do not set the first bit for now). If the current packet carries an end flag, set the corresponding direction end bit (set the second bit if the original direction is from the canonical source to the canonical destination, and set the third bit if the original direction is from the canonical destination to the canonical source), and obtain the corresponding stream state block.

[0041] Scenario 2: If the stream key is hit but the memory pointer is null, first check the total number of bytes currently occupied in memory. If the current occupancy rate plus the fixed size of the state block to be loaded (68 bytes for the direction A statistics field plus 68 bytes for the direction B statistics field plus 16 bytes for the global field, totaling 152 bytes) exceeds 95% of the physical memory capacity, execute the memory pressure eviction mechanism. Based on the solid-state disk offset pointer stored in the hash index table, read the corresponding stream serialized state block from the solid-state disk block storage area, perform deserialization operation to load it into memory, update the memory pointer in the hash index table to point to the newly loaded memory block, and perform the update operation according to Scenario 1 to obtain the corresponding stream state block.

[0042] Case 3: If the stream key is not hit, first check the total number of bytes currently occupied in memory. If the current occupancy plus the fixed size of the newly created state block (152 bytes) exceeds 95% of the physical memory capacity, execute the memory pressure eviction mechanism, create a new stream state block in memory, initialize all statistical fields to zero, store the initial sequence number of the current packet (if it is a synchronization packet) in the corresponding direction, record the current packet as the first packet in the current direction (the arrival timestamp of the first packet and the arrival timestamp of the last packet are both set to the current time), and add an entry to the hash index table. The memory pointer points to the newly created state block, the solid-state disk offset pointer is set to null, and the last arrived packet count is set to the current global packet sequence number. If the current packet is a synchronization packet, set the corresponding bit in the protocol phase marker bitmap according to Case 1 to obtain the corresponding stream state block.

[0043] At the same time, maintain a monotonically increasing global packet sequence number counter. After processing each packet, this counter is incremented by one, and the last arrived packet count of each entry is updated to the current global packet sequence number value.

[0044] After writing is complete, release the memory occupied by the corresponding stream state block, set the memory pointer of the corresponding entry in the hash index table to null, fill in the solid-state disk offset pointer, keep the last arrived packet count of the corresponding entry unchanged, move the loop eviction pointer to the next bucket position, and continue to process subsequent arriving packets. If the bucket scanned by the pointer is empty, the pointer will automatically move to the next non-empty bucket.

[0045] If a subsequent packet arrives and the corresponding stream key matches the entry but the memory pointer is empty, the pre-check logic in Case 2 is followed to ensure sufficient memory space first. Then, the serialized state block of this stream is read from the solid disk according to the solid disk offset pointer, deserialized, and reloaded into memory. The data of the new packet is merged into the corresponding direction statistics field (updated according to Case 1). At the same time, the last arriving packet count of the hash index entry is updated to the current global packet sequence number.

[0046] The keyed packets and their corresponding flow state blocks are output as stateful packet records.

[0047] The specific process of implementing the memory pressure eviction mechanism is as follows: Maintain a circular eviction pointer, initially pointing to the first bucket of the hash index table. The circular eviction pointer advances in fixed steps in the bucket space of the hash index table (the pointer advances one bucket position after each keyed packet is processed).

[0048] When memory usage exceeds 95%, starting from the bucket pointed to by the current loop eviction pointer, the hash entries in the bucket pointed to by the current loop eviction pointer are checked sequentially. The entry with the smallest last arriving packet count value in the bucket pointed to by the current loop eviction pointer (i.e. the stream that has not been updated for the longest time) is selected, and the stream state block of the corresponding entry is serialized into a fixed-format binary record.

[0049] The serialization format is defined as follows: magic number (four bytes, fixed value 0x7A3F1C2E) + stream key length (one byte, 13 or 37) + stream key binary string (thirteen or thirty-seven bytes) + direction A statistical field structure (fixed length sixty-eight bytes) + direction B statistical field structure (fixed length sixty-eight bytes) + global field structure (fixed length sixteen bytes) + cyclic redundancy checksum (four bytes, calculated over the entire serialized data). After serialization, the corresponding record is written to the next free block of the solid-state drive, and the record is written at the offset.

[0050] In one specific embodiment, the stateful packet record acquisition module abandons the traditional time-window-based stream lifecycle management by using a hash index table and a solid-state disk migration mechanism. It uses a standardized 5-tuple stream key as an index and maintains bidirectional statistical fields (68 bytes each) and a global field (16 bytes) in memory to achieve unified accounting and state tracking of bidirectional traffic within the same session. When memory occupancy reaches 95%, a cyclic eviction mechanism driven by a pointer is triggered. The least recently updated stream state is serialized (including magic number, stream key, statistical fields, and checksum) and written to the solid-state disk, releasing memory and retaining the offset pointer. This ensures strictly controllable memory usage and constant-level eviction overhead. When subsequent packets hit an already evicted stream, pre-eviction is performed to ensure sufficient space. Then, data is migrated back from the solid-state disk, deserialized, and merged. This allows slow attack payloads spanning hours to still accurately correlate with historical states. Physical memory levels replace timeout thresholds, completely resolving the dilemma of short windows failing to detect slow attacks and long windows causing memory crashes in traditional methods, while simultaneously ensuring linear processing capabilities and data consistency.

[0051] The sequence number verification module is used to verify the sequence number based on the status of the packet record and the transmission protocol type, and output the verified packet record.

[0052] If the transport protocol is Transmission Control Protocol, determine the current packet direction based on the original direction indication, and read the initial sequence number field and the total number of received bytes field from the statistics field of the corresponding direction in the flow state block. Note that since the total number of received bytes has been added to the payload length of the current packet when updating the state block, the payload length of the current packet must be subtracted when calculating the expected sequence number to obtain the historical byte count before the update. Set the historical byte count to the total number of received bytes in the current direction minus the payload length of the current packet, perform independent verification, determine the set of verification flags, and output the verified packet record.

[0053] If the transport protocol is User Datagram Protocol (UDP), read the length field (two bytes) from the UDP header, calculate the total length declared in the Internet Protocol (IP) header minus the IP header length. For IPv4, the header length is taken from the "IP header length" field in the IP header multiplied by four; for IPv6, the header length is fixed at forty bytes. If the value of the UDP length field is not equal to the total length declared in the IP header minus the IP header length, a length declaration conflict is marked and recorded in the verification flag set. If the value of the UDP length field is equal to the total length declared in the IP header minus the IP header length, the length verification passes, the verification flag set is empty, and the verified packet record is output.

[0054] The verified packet record contains keyed packets, stream state blocks, original direction indicators, and a set of verification tags. The set of verification tags contains text tags indicating missing initial sequence numbers, sequence number gaps, acknowledgment numbers leading ahead, and length declaration conflicts. If there are no anomalies, the set of verification tags is empty.

[0055] The specific process for determining the set of verification tags is as follows: Get the value of the initial sequence number field for the corresponding direction in the flow state block.

[0056] If the initial sequence number field of the corresponding direction in the flow state block is zero (indicating that the current direction has never received a synchronization packet), then the initial sequence number is marked as missing and added to the verification mark set.

[0057] If the initial sequence number field value is not zero, the expected sequence number is calculated. If the corresponding bit in the corresponding direction protocol phase marker bitmap (bit zero for source to destination and bit one for destination to source) is set, the synchronization offset is set to one; otherwise, it is set to zero. The expected sequence number is the sum of the initial sequence number, the synchronization offset, and the number of historical bytes. The sequence number field is read from the current transmission control protocol header, and the sequence number of the current packet is compared with the expected sequence number. If the current sequence number is less than the expected sequence number, no marker is generated (corresponding to a valid retransmission or duplicate packet). If the current sequence number is equal to the expected sequence number, no marker is generated. If the current sequence number is greater than the expected sequence number, a sequence number gap is marked (indicating the existence of intermediate data that has not yet arrived) and recorded in the verification marker set.

[0058] Read the acknowledgment number field from the current Transmission Control Protocol header.

[0059] Read the total number of bytes received in the reverse direction (i.e., the peer direction) from the stream status block (this is unaffected by the current packet and represents the historical number of bytes in the reverse direction), and read the initial sequence number and the synchronization offset in the reverse direction.

[0060] The expected acknowledgment number is the sum of the initial sequence number in the direction of origin, the synchronization offset in the reverse direction, and the total number of bytes received in the reverse direction. Compare the current acknowledgment number with the expected acknowledgment number: If the current confirmation number is less than or equal to the expected confirmation number, no flag is generated.

[0061] If the current acknowledgment number is greater than the expected acknowledgment number, then the acknowledgment number is marked as ahead and added to the verification flag set. This is a deterministic violation because the Transmission Control Protocol prohibits acknowledging bytes that have not yet arrived. This is a vulnerability that can be exploited by zero-day attacks when a forged acknowledgment number is used to launch an attack.

[0062] It's important to explain that signatureless attack detection achieved through protocol constraints completely eliminates the reliance on attack signatures. For the TCP protocol, the expected sequence number and expected acknowledgment number are precisely calculated using the number of cleaned historical bytes. Sequence numbers less than or equal to the expected value are considered legitimate retransmissions or in normal order and are not marked. Sequence number gaps are marked only when the sequence number exceeds the expected value, serving as observable information. If the acknowledgment number exceeds the total number of bytes sent in the reverse direction, it is considered a deterministic violation—a condition impossible in any legitimate TCP implementation, providing a vulnerability for zero-day attacks using forged acknowledgment numbers. For the UDP protocol, the consistency between its header length field and the IP layer declaration is strictly compared, marking "length declaration conflict." Verification is based on mandatory fields of the protocol standard, without involving any statistical baselines or machine learning, ensuring reproducible and unambiguous detection results. Legitimate network jitter (retransmissions, out-of-order delivery) is clearly separated from genuine attack behavior, significantly reducing the false positive rate while maintaining a high detection rate, providing a clean and reliable set of verification tags for subsequent adjudication modules.

[0063] The encryption protocol inspection module is used to determine whether the verified packet record is an encryption protocol carrier. If the verified packet record is an encryption protocol carrier, the encryption protocol inspection is performed and the encrypted verified packet record is output. If the verified packet record is not an encryption protocol carrier, the verified packet record is directly output as an encrypted verified packet record.

[0064] To determine whether the current packet carries a transport layer security protocol record, the identification criteria are as follows: a. The current packet transmission protocol is Transmission Control Protocol.

[0065] b. The total length of the current packet payload is at least five bytes.

[0066] c. The value of the first byte of the current packet payload belongs to the set {0x14, 0x15, 0x16, 0x17} (corresponding to four content types: change password specification, alarm, handshake, and application data, respectively).

[0067] If all identification conditions are met, the current packet is considered as an encrypted protocol bearer packet.

[0068] For the current packet identified as an encrypted protocol bearer, extract three fixed fields from the record header at the beginning of the payload: content type, protocol version, and record length. Perform an encryption protocol check and output the encrypted and verified packet record.

[0069] The specific process for checking the encryption protocol is as follows: The value of the content type field must belong to the set {0x14, 0x15, 0x16, 0x17}. If it does not belong, an unreasonable content type flag is triggered and recorded in the verification flag set.

[0070] The high-order byte of the protocol version field must be equal to 0x03, and the low-order byte must belong to the set {0x01, 0x02, 0x03, 0x04} (corresponding to Transport Layer Security Protocol versions 1.0, 1.1, 1.2, and 1.3, respectively). If it does not meet the requirements, an unreasonable protocol version flag is triggered and recorded in the verification flag set.

[0071] The value of the record length field must be greater than or equal to one and less than or equal to 16384. The upper and lower limits are derived from the fixed maximum payload length of plaintext records in the Transport Layer Security Protocol Standard Specification (RFC8446). If the record length is zero, a record length zero value flag is triggered and recorded in the verification flag set. If the record length is greater than 16384, a record length over-limit flag is triggered and recorded in the verification flag set.

[0072] Output the encrypted and verified packet record.

[0073] If the verified packet record is not an encrypted protocol bearer packet, the verified packet record will be directly output as an encrypted and verified packet record.

[0074] In one specific embodiment, the challenge of a high proportion of encrypted traffic is effectively addressed by verifying only the plaintext header without decryption. The encrypted payload is accurately identified based on the fixed format of the first five bytes of the Transport Layer Security (TLS) protocol record. Verification based on the RFC8446 standard is performed on three fixed plaintext fields: content type, protocol version, and record length. The content type must belong to the standard enumeration set; the protocol version's high-order byte is fixed at 0x03, and the low-order version number must be between 1.0 and 1.3; the record length must be between 1 and 16384 bytes. These verification conditions are all protocol-mandated and non-negotiable deterministic constraints. Attackers cannot hide malformed structures in these header fields through the encrypted payload. Any violation is marked as a deterministic violation. Malformed encrypted traffic can be identified without decrypting any payload data. The processing overhead is extremely low and completely unaffected by the encryption algorithm strength, ensuring line-speed processing capabilities in high-speed backbone network environments. Simultaneously, it provides independent and reproducible evidence of violations for subsequent adjudication modules.

[0075] The adjudication result output module is used to perform one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection based on the encrypted and verified packet records, and output the final adjudication result record.

[0076] The total number of packets and bytes sent from the source to the destination of the specification, and the total number of packets and bytes sent from the destination to the source of the specification.

[0077] If the current packet belongs to the canonical source to the canonical destination, and the total number of received packets from the canonical source to the canonical destination in the flow state block is greater than three, while the total number of received packets from the canonical destination to the canonical source is equal to zero, then this flow is marked as unidirectional continuous flow. If the current packet belongs to the canonical destination to the canonical source, and the total number of received packets from the canonical destination to the canonical source is greater than three, while the total number of received packets from the canonical source to the canonical destination is equal to zero, then it is also marked as unidirectional continuous flow.

[0078] If it is a Transmission Control Protocol (TCP), check bit zero (the source-to-destination synchronization flag has been received) and bit one (the destination-to-source synchronization acknowledgment flag has been received) of the protocol phase flag bitmap in the flow state block. If bit zero is not set or bit one is not set, the corresponding flow is marked as having an incomplete handshake.

[0079] If it is User Datagram Protocol (UDP), check the total number of packets since the arrival of the first packet in the flow state block (the number of packets from the canonical source to the canonical destination plus the number of packets from the canonical destination to the canonical source). If the total number of packets is greater than ten and the packet count in the opposite direction to the current packet is zero, then mark the corresponding flow as no-response traffic.

[0080] Execute the final alarm ruling logic and output the final ruling result record.

[0081] The specific process of executing the final alarm adjudication logic and outputting the final adjudication result record is as follows: If the verification flag set contains any of the following: acknowledgment number leading, unreasonable content type, unreasonable protocol version, record length zero, record length exceeding limit, incomplete handshake, one-way continuous traffic, or no-response traffic, then the current record will be classified as an attack-suspect record and an alarm will be output. The alarm content includes the flow key (canonical 5-tuple binary string converted to hexadecimal readable representation), the trigger flag type list, and the cumulative packet count from the canonical source to the canonical destination and from the canonical destination to the canonical source.

[0082] If the verification tag set contains only sequence number gaps or the initial sequence number is missing, no alarm is generated; only the internal copy of this packet record is discarded to free up memory.

[0083] If the set of verification tags is empty, no alarm is generated, and only the internal copy is discarded.

[0084] Through a multi-dimensional fusion detection and hierarchical alarm mechanism, a closed loop from packet-level verification to flow-level behavior determination is achieved. Based on the bidirectional packet counters in the flow state block, three deterministic decisions are executed: unidirectional persistent traffic detection determines unidirectional behavior when the reverse packet count is zero; handshake integrity detection ensures that the synchronization sequence number and synchronization acknowledgment flag of the Transmission Control Protocol appear in pairs; and no-response traffic detection uses a total packet count threshold to capture unidirectional sweeps of the User Datagram Protocol. All thresholds are fixed constants and do not depend on statistical baselines or time windows. The final hierarchical alarm logic treats deterministic violation markers such as leading acknowledgment numbers, illegal Transport Layer Security (TLS) headers, and incomplete handshakes as attack evidence, immediately outputting a structured alarm containing the flow key and cumulative packet count. Legitimate network jitter markers such as sequence number gaps are explicitly excluded from alarms, effectively distinguishing between genuine attacks and normal retransmissions / out-of-order delivery, ensuring that alarm results are interpretable and reproducible, significantly reducing false alarm rates, and providing a high-confidence decision-making basis for security operations and maintenance.

[0085] Reference Figure 2 As shown, the second aspect of the present invention provides a network intrusion detection method, comprising the following steps: Based on the original data packet, perform normalization processing to generate a canonical quintuple and construct a fixed-length binary string as the stream key. Extract the initial sequence number and output the keyed packet.

[0086] Based on keyed packets, the hash index table is queried using the stream key in the keyed packet as an index to obtain the packet record with state.

[0087] Based on the stateful packet records and the transmission protocol type, sequence number verification is performed, and verified packet records are output.

[0088] For a verified packet record, determine whether the verified packet record is an encrypted protocol bearer. If the verified packet record is an encrypted protocol bearer, perform an encryption protocol check and output the encrypted verified packet record. If the verified packet record is not an encrypted protocol bearer, directly output the verified packet record as the encrypted verified packet record.

[0089] Based on the encrypted and verified packet records, one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection are performed, and the final decision result record is output.

[0090] The above description is merely an example and illustration of the structure of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the structure of the invention or exceed the scope defined in the claims, all of which should fall within the protection scope of the present invention.

Claims

1. A network intrusion detection system, characterized in that, include: The raw data packet parsing module is used to perform normalization processing on the raw data packet to generate a normalized quintuple and construct a fixed-length binary string as the stream key, extract the initial sequence number, and output the keyed packet; The stateful packet record acquisition module is used to retrieve stateful packet records by querying a hash index table based on keyed packets and using the stream key in the keyed packets as an index. The sequence number verification module is used to verify the sequence number based on the status-bearing packet record and the transmission protocol type, and output the verified packet record. The encryption protocol inspection module is used to determine whether the verified packet record is an encryption protocol carrier. If the verified packet record is an encryption protocol carrier, the encryption protocol inspection is performed and the encrypted and verified packet record is output. If the verified packet record is not an encryption protocol carrier, the verified packet record is directly output as the encrypted and verified packet record. The adjudication result output module is used to perform one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection based on the encrypted and verified packet records, and output the final adjudication result record.

2. The network intrusion detection system according to claim 1, characterized in that, Based on the original data packet, the specific process of performing normalization to generate a canonical quintuple and constructing a fixed-length binary string as the stream key, extracting the initial sequence number, and outputting the keyed packet is as follows: Based on the original data packet, extract the source Internet Protocol address, destination Internet Protocol address, source port number, destination port number, and transport protocol type, and record them as the original 5-tuple; Normalize the original quintuple to obtain the normalized quintuple; Record the orientation of the original quintuple relative to the canonical quintuple. If the original source Internet Protocol address is equal to the canonical source Internet Protocol address and the original source port number is equal to the canonical source port number, then the original direction is from direction A to direction B. Otherwise, the original direction is from direction B to direction A. A is the canonical source and B is the canonical destination. The canonical quintuples are concatenated into a fixed-length binary string according to network byte order, and denoted as the stream key of the hash index operation; Check the synchronization flag in the Transmission Control Protocol header. If the synchronization flag is set, read the initial sequence number field from the Transmission Control Protocol header. If the synchronization flag is not set, set the initial sequence number field to zero. Output the stream key, the original direction of the original quintuple relative to the canonical quintuple, and the initial sequence number field as a keyed packet.

3. The network intrusion detection system according to claim 1, characterized in that, The specific process of querying the hash index table using the stream key in the keyed packet as an index to obtain the packet record with state is as follows: Use the stream key in the keyed packet as the index to query the hash index table; Case 1: If the stream key is matched and the memory pointer is not null, the ledger of the corresponding stream is found in memory, the number of packets, the number of bytes, the timestamp and the protocol flag are updated, and the corresponding stream state block is obtained; Case 2: If the stream key is hit but the memory pointer is empty, first check the total number of bytes currently occupied in memory. If the current occupancy rate plus the fixed size of the state block to be loaded exceeds 95% of the physical memory capacity, execute the memory pressure eviction mechanism, read back the old ledger from the solid-state drive and load it into memory, and perform the update operation according to Case 1 to obtain the corresponding stream state block. Case 3: If the stream key is not hit, first check the total number of bytes currently occupied in memory. If the current occupancy rate plus the fixed size of the newly created state block exceeds 95% of the physical memory capacity, execute the memory pressure eviction mechanism. After the memory pressure eviction mechanism is completed, create a blank ledger in memory, fill in the first packet information, and obtain the corresponding stream state block. The keyed packets and their corresponding flow state blocks are output as stateful packet records.

4. The network intrusion detection system according to claim 3, characterized in that, The specific process of implementing the memory pressure eviction mechanism is as follows: Maintain a circular eviction pointer, initially pointing to the first bucket of the hash index table. The circular eviction pointer advances in fixed steps within the bucket space of the hash index table. When memory usage exceeds 95%, starting from the bucket pointed to by the current loop eviction pointer, the hash entries in the bucket pointed to by the current loop eviction pointer are checked sequentially. The entry with the smallest last arriving packet count value in the bucket pointed to by the current loop eviction pointer is selected, and the stream state block of the corresponding entry is serialized into a fixed-format binary record.

5. The network intrusion detection system according to claim 1, characterized in that, The specific process of checking the sequence number based on the transmission protocol type and outputting the verified packet record is as follows: If the transport protocol is a transmission control protocol, determine the current packet direction based on the original direction indication, read the initial sequence number field and the total number of received bytes field from the statistics field of the corresponding direction in the stream state block, perform independent verification, determine the set of verification flags, and output the verified packet record; If the transport protocol is User Datagram Protocol (UDP), read the length field from the UDP header, calculate the total length declared in the Internet Protocol header minus the Internet Protocol header length. If the value of the UDP length field is not equal to the total length declared in the Internet Protocol header minus the Internet Protocol header length, then mark the length declaration as conflict and add it to the verification flag set. If the value of the UDP length field is equal to the total length declared in the Internet Protocol header minus the Internet Protocol header length, then the length verification passes, the verification flag set is empty, and the verified packet record is output. The verified packet record contains keyed packets, a flow state block, an original direction indicator, and a set of verification tags.

6. The network intrusion detection system according to claim 5, characterized in that, The specific process of performing independent verification and determining the set of verification tags is as follows: Get the value of the initial sequence number field for the corresponding direction in the flow state block; If the initial sequence number field value in the corresponding direction in the flow state block is zero, then the initial sequence number is marked as missing and recorded in the verification mark set; If the initial sequence number field value is not zero, the expected sequence number is calculated. If the corresponding bit in the corresponding direction protocol stage marker bitmap has been set, the synchronization offset is set to one; otherwise, it is set to zero. The expected sequence number is the sum of the initial sequence number, the synchronization offset, and the number of historical bytes. The sequence number field is read from the current transmission control protocol header. The sequence number of the current packet is compared with the expected sequence number. If the current sequence number is less than the expected sequence number, no marker is generated. If the current sequence number is equal to the expected sequence number, no marker is generated. If the current sequence number is greater than the expected sequence number, the sequence number gap is marked and recorded in the verification marker set. Read the acknowledgment number field from the current Transmission Control Protocol header; Read the total number of bytes received in the reverse direction from the stream status block, and read the initial sequence number and the synchronization offset in the reverse direction. The expected acknowledgment number is the sum of the initial sequence number in the direction, the synchronization offset in the reverse direction, and the total number of bytes received in the reverse direction. Compare the current confirmation number with the expected confirmation number: If the current confirmation number is less than or equal to the expected confirmation number, no flag is generated; If the current confirmation number is greater than the expected confirmation number, then mark the confirmation number as ahead and add it to the verification mark set.

7. The network intrusion detection system according to claim 1, characterized in that, The process of determining whether a verified packet record is an encrypted protocol bearer is as follows: If the verified packet record is an encrypted protocol bearer, an encryption protocol check is performed, and the encrypted verified packet record is output. If the verified packet record is not an encrypted protocol bearer, the verified packet record is directly output as an encrypted verified packet record. To determine whether the current packet carries a transport layer security protocol record, the identification criteria are as follows: a. The current packet transmission protocol is Transmission Control Protocol; b. The total length of the current packet payload is at least five bytes; c. The value of the first byte of the current packet payload belongs to the set {0x14, 0x15, 0x16, 0x17}; If all identification conditions are met, the current packet is considered as an encrypted protocol bearer packet; For the current packet identified as an encrypted protocol bearer, extract three fixed fields from the record header at the beginning of the payload: content type, protocol version, and record length, perform an encryption protocol check, and output the encrypted and verified packet record; If the verified packet record is not an encrypted protocol bearer packet, the verified packet record will be directly output as an encrypted and verified packet record.

8. The network intrusion detection system according to claim 1, characterized in that, The specific process of performing one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection, and outputting the final decision record is as follows: The total number of packets and bytes sent from the source of the specification to the destination of the specification, and the total number of packets and bytes sent from the destination of the specification to the source of the specification; If the current packet belongs to the canonical source to the canonical destination, and the total number of received packets from the canonical source to the canonical destination in the flow state block is greater than three, while the total number of received packets from the canonical destination to the canonical source is equal to zero, then this flow is marked as unidirectional continuous flow. If the current packet belongs to the canonical destination to the canonical source, and the total number of received packets from the canonical destination to the canonical source is greater than three, while the total number of received packets from the canonical source to the canonical destination is equal to zero, then it is also marked as unidirectional continuous flow. If it is a transmission control protocol, check the zeroth and first bits of the protocol phase flag bitmap in the stream status block. If the zeroth bit is not set or the first bit is not set, mark the corresponding stream as having an incomplete handshake. If it is User Datagram Protocol, check the total number of packets since the first packet arrived in the flow state block. If the total number of packets is greater than ten and the packet count in the opposite direction of the current packet is zero, then mark the corresponding flow as no-response traffic. Execute the final alarm ruling logic and output the final ruling result record.

9. The network intrusion detection system according to claim 8, characterized in that, The specific process of executing the final alarm adjudication logic and outputting the final adjudication result record is as follows: If the verification flag set contains any of the following: acknowledgment number precedence, unreasonable content type, unreasonable protocol version, record length zero, record length exceeding limit, incomplete handshake, one-way continuous traffic, or no-response traffic, then the current record will be classified as an attack-suspected record and an alarm will be output. The alarm content includes the flow key, the list of trigger flag types, and the cumulative number of packets from the source to the destination and from the destination to the source. If the verification mark set contains only serial number gaps or the initial serial number is missing, no alarm will be generated; If the set of verification tags is empty, no alarm will be generated.

10. A network intrusion detection method, applied to the network intrusion detection system according to any one of claims 1-9, characterized in that, Includes the following steps: Based on the original data packet, perform normalization to generate a normalized quintuple and construct a fixed-length binary string as the stream key. Extract the initial sequence number and output the keyed packet. Based on keyed packets, the hash index table is queried using the stream key in the keyed packet as an index to obtain the packet record with state; Based on the stateful packet records and combined with the transmission protocol type, sequence number verification is performed, and verified packet records are output. For a verified packet record, determine whether the verified packet record is an encrypted protocol bearer. If the verified packet record is an encrypted protocol bearer, perform an encryption protocol check and output the encrypted verified packet record. If the verified packet record is not an encrypted protocol bearer, directly output the verified packet record as the encrypted verified packet record. Based on the encrypted and verified packet records, one-way continuous traffic detection, handshake integrity detection, and no-response traffic detection are performed, and the final decision result record is output.

Images