Network isolated data exchange method based on protocol restoration and content filtering

Abstract

The application relates to the technical field of data exchange, and discloses a network isolated data exchange method based on protocol restoration and content filtering, which comprises the following steps: capturing data packets, recombining sessions according to five tuples, obtaining session flows, byte streams and message byte sequences; obtaining protocol identification results of the session flows, converting byte values in the byte streams into operation codes, dividing byte intervals, realizing field division, extracting statistical features of the fields, inferring data types and operation semantics, identifying legal data, constructing a protocol analysis template and a feature retrieval tree, and performing field analysis on all protocol identification results; and performing safe exchange on the legal data filtered according to the content. The application aims to improve the protocol identification precision of cross-network safe exchange technology.

Description

Technical Field

[0001] This application relates to the field of data exchange technology, specifically to a network isolation data exchange method based on protocol restoration and content filtering. Background Technology

[0002] Computer networks are a crucial technology for information collection and processing, but their rapid development has also brought numerous security vulnerabilities. For computer information systems involving important secrets, physical isolation is necessary to prevent information leaks and significant losses. Existing secure cross-network exchange technologies primarily rely on protocol identification and content inspection, which have significant shortcomings.

[0003] Specifically, existing technologies for identifying network gateway protocols rely heavily on static feature libraries, and can only parse standard publicly available application protocols. They are difficult to adapt to the private, unknown protocols and dynamic variations of protocols widely used in scenarios such as industrial control, IoT, and financial transactions, resulting in low identification accuracy. At the same time, the content inspection process lacks contextual semantic understanding, and keyword filtering and regular expression matching can easily lead to an increased false alarm rate, failing to solve the accuracy problems of fine-grained protocol restoration and content filtering. Summary of the Invention

[0004] This application provides a network isolation data exchange method based on protocol restoration and content filtering to solve the problem of increased false alarm rate caused by the low protocol identification accuracy in cross-network secure exchange technology. The specific technical solution adopted is as follows:

[0005] One embodiment of this application provides a network isolation data exchange method based on protocol restoration and content filtering, the method comprising the following steps:

[0006] Capture data packets, reassemble the session according to the five-tuples, and obtain the session stream, the corresponding byte stream, and the message byte sequence;

[0007] Based on the message byte sequence of the session stream, the protocol identification result of the session stream is identified through a neural network. The protocol identification result includes known protocol categories and unknown protocols. The byte values ​​in the byte stream are converted into opcodes according to a preset block length. Combining the differences in byte values ​​at adjacent positions in the byte stream of the session stream, all different positions in the byte stream of the session stream are clustered. The byte intervals are divided according to the clustering results to achieve field partitioning. The fields are represented by quadruples, which include offset, length, data type, and operation semantics. Statistical features are extracted from the fields, and the data type and operation semantics are inferred to identify legal data. Based on the quadruples of all fields partitioned from the byte stream of the session stream, a protocol parsing template and a feature retrieval tree are constructed. The protocol parsing template corresponding to the unknown protocol is re-determined based on the feature retrieval tree. Field parsing is performed on all protocol identification results.

[0008] Perform fine-grained field-level checks on legitimate data to achieve content filtering, and physically isolate and exchange legitimate data that has passed content filtering to achieve secure exchange of network-isolated data.

[0009] Furthermore, the session stream and the byte stream are specifically as follows:

[0010] Data packets with consistent 5-tuple characteristics among the captured data packets are identified as belonging to the same logical conversation. They are then sorted and deduplicated according to TCP sequence numbers to obtain the session stream and byte stream. The 5-tuple includes the source IP address, destination IP address, transport layer protocol, source port, and destination port.

[0011] Furthermore, the specific method for identifying the protocol identification result of the session stream is as follows:

[0012] The message byte sequence of the session stream is truncated and normalized to obtain a tensor of a preset dimension. The tensor is used as the input of the 1D-CNN model to obtain the probability vector of the session stream.

[0013] The protocol category corresponding to the maximum value in the probability vector that is greater than or equal to the preset protocol recognition threshold is selected as the protocol recognition result of the known protocol category; otherwise, the unknown protocol is selected as the protocol recognition result of the corresponding session stream.

[0014] Furthermore, the opcode includes:

[0015] Bytes 0x00 to 0x0F are mapped to OP_CONST_SMALL, bytes 0xFF and 0xFE are mapped to OP_MAGIC_HEADER, consecutive ASCII character range bytes are mapped to OP_ASCII_CHAR, and bytes that do not match predefined rules are directly mapped to the OP_RAW_BYTE_XX category according to their hexadecimal values.

[0016] Furthermore, the method for obtaining the clustering results is as follows:

[0017] Take any position in the byte stream of the session stream as the center, establish a window of a preset window length, calculate the Shannon entropy of all byte values ​​in the window, and record the absolute value of the difference between any position in the byte stream of the session stream and the byte value of the previous adjacent position as the first-order absolute difference value of that position. The normalized value of the Shannon entropy of the window determined by any position in the byte stream of the session stream and the mean of the normalized value of the first-order absolute difference value of the position are recorded as the boundary weight of the corresponding position.

[0018] For any opcode in the abstract opcode sequence of the byte stream, the opcode is transformed into an opcode vector using a Skip-gram-based feature embedding algorithm. The context co-occurrence distance between two opcode vectors at different positions in the byte stream of the session stream is denoted as the first distance between the two different positions in the byte stream of the session stream.

[0019] The second distance between two different positions in the byte stream of the session stream is calculated based on the difference in boundary weights and order in the byte stream.

[0020] The weighted sum of the first distance and the second distance between two different positions in the byte stream of the session stream is denoted as the similarity distance between the two different positions in the byte stream of the session stream.

[0021] The similarity distance between different positions in the byte stream of the session stream is used as the distance between different positions. All different positions in the byte stream of the session stream are clustered to obtain clusters.

[0022] Furthermore, the specific method for calculating the second distance between two different positions in the byte stream of the session stream is as follows:

[0023] The sum of the mean of the boundary weights at two different positions in the byte stream of the session stream and the preset positive constant is denoted as the first fraction at two different positions in the byte stream of the session stream.

[0024] The numerator is the sum of the absolute value of the difference between the order of two different positions in the byte stream of the session stream and the number 1, the denominator is the number of positions in the byte stream, and the fraction is the second fraction corresponding to the two different positions.

[0025] The product of the first and second fractions at two different positions in the byte stream of the session stream is denoted as the second distance between the two different positions in the byte stream of the session stream.

[0026] Furthermore, the statistical features extracted from the fields include:

[0027] The field offset, the field's byte length, whether all byte sequences corresponding to all byte intervals divided by the cluster are completely consistent, whether all byte sequences corresponding to all byte intervals divided by the cluster can be parsed as unsigned integers, whether the proportion of printable ASCII characters in all byte sequences corresponding to all byte intervals divided by the cluster exceeds 80%, whether the numeric bytes arranged in message order are strictly monotonically increasing, and the distance from the end of the field.

[0028] Furthermore, the specific methods for constructing the protocol parsing template and feature retrieval tree are as follows:

[0029] Get the quadruple of all fields from the byte stream of the session stream, sort all fields from the byte stream of the session stream in ascending order according to the field offset, and get the protocol parsing template;

[0030] The operational semantics of the fields include command words, length fields, checksums, sequence numbers, data payloads, and unknown data. The protocol parsing template is traversed to extract fields whose operational semantics are command words. The specific byte values ​​and offsets of the fields in the byte stream of the session stream are used as the feature fingerprints of the corresponding unknown protocols. If the command word field is not identified in the protocol parsing template, the first 4 bytes at the preset position are extracted as feature fingerprints.

[0031] The feature retrieval tree consists of a root node, internal nodes, and leaf nodes. Each node contains four attributes: byte value, offset, array of child node pointers, and template pointer.

[0032] Furthermore, the specific method for parsing the field is as follows:

[0033] Get the quadruple corresponding to the field, slide the pointer to the byte offset position of the field, read binary data of the corresponding length, and perform data type conversion according to the data type of the field;

[0034] The converted data and corresponding operation semantics are stored in the protocol parsing table as key-value pairs.

[0035] Furthermore, the field-level fine-grained inspection specifically includes:

[0036] When the operation semantics are command words, they are compared with the preset read and write command whitelist. If an unauthorized high-risk command is found, the session is blocked.

[0037] When the operation semantics are data payloads, regular expressions are used to scan the payload content for virus signatures and filter sensitive keywords.

[0038] Verify checksums and their validity, and filter maliciously tampered messages;

[0039] By combining the protocol session context state, we can establish a correlation analysis between operational semantics and data dimensions.

[0040] The beneficial effects of this application are:

[0041] This application first reassembles discrete data packets and accurately segments message boundaries, automatically inferring the boundaries and internal field structures of unknown protocols from unordered binary byte streams, and generating standard four-tuple descriptions. This provides a high-quality data foundation for subsequent protocol parsing, avoiding issues such as misjudgment of sensitive characters and false session blocking caused by ambiguous protocol boundary divisions, thus improving the accuracy and reliability of protocol identification and parsing. Then, it performs differentiated security checks based on field operation semantics and conducts correlation analysis in conjunction with session context state, parsing fields for known protocol categories and unknown protocols separately. This effectively intercepts unauthorized high-risk commands, malicious message tampering, and covert channel attacks, improving the targeting and security of content filtering, and reducing false positive and false negative rates. Furthermore, a feature retrieval tree is constructed during the above process, requiring only minimal time complexity to perform retrieval. Prefix matching allows for direct application of parsing templates for structured reconstruction, perfectly meeting the high throughput and low latency performance requirements of network isolation environments. Furthermore, establishing protocol parsing templates enables fine-grained field-level checks, conducting multi-dimensional security assessments based on different semantics and context states, effectively intercepting covert channel attacks, and reducing false alarm and false negative rates in data exchange. This constructs a protocol-free isolated data exchange mechanism, securely exchanging legitimate data that has undergone content filtering, stripping away all standard network protocol-related information, and achieving dual physical and logical isolation between internal and external networks. This fundamentally immunizes against various network layer attacks targeting the TCP / IP protocol stack, ensuring the security and independence of data exchange between isolated networks, and resolving the issue of increased false alarm rates due to protocol identification accuracy issues in cross-network secure exchange technologies, thus ensuring the security of network-isolated data exchange. Attached Figure Description

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

[0043] Figure 1 This is a schematic flowchart of a network isolation data exchange method based on protocol restoration and content filtering provided in one embodiment of this application. Detailed Implementation

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

[0045] Please see Figure 1 The diagram illustrates a flowchart of a network isolation data exchange method based on protocol restoration and content filtering according to an embodiment of this application. The method includes the following steps:

[0046] Step S001: Capture data packets, reassemble the session according to the five-tuple, and obtain the session stream, the corresponding byte stream, and the message byte sequence.

[0047] Protocol restoration is a key technical support for achieving deep content filtering during network isolated data exchange. The role of this step is to realize traffic capture and session reassembly, restoring the application layer protocol encapsulated in the bit stream in network communication into a formatted information object with a clear syntactic structure and interactive semantics.

[0048] This embodiment connects independent host systems on both internal and external networks using an isolation switching module to achieve the highest level of network security. The isolation switching module is a solid-state switch and read / write medium with multiple control functions, capable of connecting two independent host systems simultaneously. Between the networks on either side of the isolation switching module, all TCP / IP connections must undergo complete application protocol restoration on the corresponding host system. Deployed at the boundary of the isolated network, when an access request reaches the internal or external host system, it first terminates the TCP connection to ensure that the TCP / IP protocol does not penetrate the network directly or through a proxy. Subsequently, the internal and external host systems preprocess the access request according to security policies, determining whether it complies with access control policies and performing application layer protocol checks and content filtering on the data packets to verify the legality and security of their payloads.

[0049] Once a data packet passes security checks, both internal and external network host systems format it, enabling unidirectional exchange via an isolated switching module by formatting data blocks. This method physically isolates and blocks all potentially attackable connections while achieving the highest level of security through mandatory content inspection, effectively preventing threats exploiting various known or unknown network layer vulnerabilities.

[0050] Building upon secure preprocessing and unidirectional switching, the isolation switching module bypasses the traditional kernel protocol stack using kernel bypass technologies such as DPDK / PF_RING, directly mapping network data to user space via Direct Memory Access (DMA). Simultaneously, it utilizes a ring buffer and large pages to achieve zero-copy traffic capture, ensuring line-rate processing with no packet loss in high-throughput scenarios. Subsequently, this module takes over and terminates all TCP / IP connections in user space, performing protocol conversion and isolation switching on the stripped application-layer data.

[0051] Because the captured raw data packets are discrete and out of order, they need to be clustered and reassembled based on a five-tuple (source IP address, destination IP address, transport layer protocol, source port, destination port) to reconstruct the complete application layer session. Specifically, a hash table is maintained in both internal and external network host systems, using the five-tuple as the key and a dynamic buffer as the value. To achieve bidirectional session association, the five-tuple needs to be symmetrically processed. For each arriving data packet, its five-tuple hash value is calculated, and its application layer payload is stored in the corresponding buffer according to its sequence number. Out-of-order packet handling and retransmission issues are addressed in real time. Simultaneously, a timer mechanism is introduced to manage the hash table, promptly releasing closed or timed-out session buffers to prevent memory overflow.

[0052] The core logic of session reassembly is as follows: among all captured raw data packets, data packets with completely identical five-tuple characteristics are selected and determined to be the same logical conversation. By sorting and deduplicating the data in the buffer according to the TCP sequence number, the final output is an ordered and complete session stream and byte stream.

[0053] It is understandable that a session stream represents each session, including various information such as the session object and session data, while a byte stream represents the data information in each session.

[0054] To segment application layer messages in a TCP streaming session, a preset time interval threshold is used; in this embodiment, the threshold is set to 100 milliseconds. Data packets arriving sequentially in the session are traversed. If the arrival time difference between adjacent data packets exceeds the preset time interval threshold, or if the TCP PSH flag of the preceding adjacent data packet is valid, this is identified as a message boundary. Based on all identified boundaries, the data packet payload sequence is segmented into multiple independent and complete message byte sequences, which serve as input samples for subsequent protocol analysis.

[0055] By following the steps above, a structured session byte stream that can be used for in-depth protocol analysis can be obtained, along with a complete message byte sequence.

[0056] At this point, the session stream, byte stream, and message byte sequence have been obtained.

[0057] Step S002: Based on the message byte sequence of the session stream, the protocol identification result of the session stream is identified through a neural network. The protocol identification result includes known protocol categories and unknown protocols. The byte values ​​in the byte stream are converted into opcodes according to a preset block length. Combining the differences in byte values ​​at adjacent positions in the byte stream of the session stream, all different positions in the byte stream of the session stream are clustered. The byte intervals are divided according to the clustering results to achieve field partitioning. The fields are represented by quadruples, which include offset, length, data type, and operation semantics. Statistical features are extracted from the fields, and the data type and operation semantics are inferred to identify legal data. Based on the quadruples of all fields partitioned from the byte stream of the session stream, a protocol parsing template and a feature retrieval tree are constructed. The protocol parsing template corresponding to the unknown protocol is re-determined based on the feature retrieval tree. Field parsing is performed on all protocol identification results.

[0058] Traditional protocol identification methods based on port or fixed feature codes have low accuracy and struggle to handle unknown protocols and dynamically allocated ports. This embodiment employs a one-dimensional convolutional neural network to identify network protocol types, automatically learning protocol features from the message byte sequence of the session stream, thus improving identification accuracy and adaptability.

[0059] The message byte sequence of the session stream is truncated and normalized to obtain a tensor of a preset dimension. The tensor is then used as the input to a 1D-CNN model to obtain the probability vector of the session stream.

[0060] The tensor normalization process of 1D-CNN is as follows: the decimal value of each byte is divided by 255 and mapped to the range [0,1].

[0061] Specifically, the first 1024 bytes of the message byte sequence in the session stream are selected to form a tensor of dimension (1024, 1). The tensor is normalized to map the value of each byte to the interval [0, 1], thereby accelerating the convergence of the 1D-CNN model and improving the recognition accuracy. When the message byte sequence is less than 1024 bytes, it is padded with zeros to 1024 bytes. When the message byte sequence exceeds 1024 bytes, it is truncated to the first 1024 bytes. That is, only the first 1024 bytes of the message byte sequence are selected.

[0062] It is important to understand that the probability vector of a session stream is a probability vector corresponding to the total number of protocol categories, and each element in the vector represents the probability that the session belongs to the corresponding protocol category.

[0063] The 1D-CNN model in this embodiment is trained using historical network traffic data annotated with one-hot encoding, and the loss function used is cross-entropy loss. During model recognition, the protocol category corresponding to the maximum value in the probability vector is selected as the protocol recognition result. At this point, the protocol category is a known protocol category. If the maximum value in the probability vector is lower than a preset protocol recognition threshold, then an unknown protocol is used as the protocol recognition result for the corresponding session flow. In this embodiment, the protocol recognition threshold is set to 0.6.

[0064] The 1D-CNN model network structure, from input to output, consists of convolutional layers, max-pooling layers, convolutional layers, max-pooling layers, flattening layers, and fully connected layers. Specifically, in order of input to output, each layer is as follows: the convolutional layer uses 64 filters with a width of 5 and the ReLU activation function; the max-pooling layer has a pooling window size of 2; the convolutional layer uses 128 filters with a width of 5 and the ReLU activation function; the max-pooling layer has a pooling window size of 2; the flattening layer converts multi-dimensional feature maps into one-dimensional vectors; the fully connected layer contains 256 neurons, uses the ReLU activation function, and sets a dropout rate of 0.5 to prevent overfitting; the output layer has the same number of neurons as the total number of protocol categories to be classified, and uses the Softmax activation function.

[0065] Traditional binary protocol reverse engineering methods rely on semantic similarity between instructions for field segmentation, which lacks sensitivity to key areas such as command words and length fields in protocol frames, easily leading to misjudgment of field boundaries. To avoid these problems, this paper improves the accuracy of field boundary identification by calculating the importance weight of each position in the message byte sequence and accurately inferring the internal field structure of each application layer message from the session stream from which the protocol identification results are obtained.

[0066] The block length is set to 1 byte, dividing the session stream's byte stream into continuous, non-overlapping, fixed-length blocks; a set of abstract opcodes is defined for each byte value or combination of byte values ​​through a predefined mapping table, converting the byte stream into a sequence of abstract opcodes.

[0067] Specifically, the predefined mapping table in this embodiment maps bytes 0x00 to 0x0F to OP_CONST_SMALL, bytes 0xFF and 0xFE to OP_MAGIC_HEADER, consecutive ASCII character range bytes to OP_ASCII_CHAR, and bytes that do not match the predefined rules are directly mapped to the OP_RAW_BYTE_XX category according to their hexadecimal values.

[0068] Among them, bytes 0x00, 0x0F, 0xFF, and 0xFE are all hexadecimal, and the ASCII character range corresponds to hexadecimal 0x20-0x7E.

[0069] A window of a preset length is established centered at any position in the byte stream of the session stream. The Shannon entropy of the window is calculated based on all byte values ​​within the window. The absolute value of the difference between the byte value at any position in the byte stream of the session stream and the byte value at the previous adjacent position is denoted as the first-order absolute difference value of that position. The normalized value of the Shannon entropy of the window determined at any position in the byte stream of the session stream and the mean of the normalized value of the first-order absolute difference value of the position are denoted as the boundary weight of the corresponding position.

[0070] In this embodiment, the preset window length is set to 9. It should be noted that this embodiment uses the maximum and minimum value normalization method to calculate the normalized value. In actual application, implementers may use other methods of existing technology, such as the tanh function and the sigmoid function, to calculate the normalized value, which is not limited here.

[0071] In the normalization process of the absolute value of the first-order difference, the maximum value is set to 255 and the minimum value is set to 0; the normalization process of Shannon entropy uses the theoretical maximum and minimum Shannon entropy as extreme values. When calculating Shannon entropy, for positions at the beginning or end of the byte stream that are less than the preset window length, edge padding with zeros is used to fill the window length.

[0072] The larger the Shannon entropy of the window, the more random the byte values ​​within the window, and the higher the complexity of the value selection.

[0073] For any opcode in the abstract opcode sequence of the byte stream, the opcode is transformed into an opcode vector using a Skip-gram-based feature embedding algorithm. The context co-occurrence distance between opcode vectors at two different positions in the session stream's byte stream is denoted as the first distance between the two different positions in the session stream's byte stream. The sum of the mean of the boundary weights at two different positions in the session stream's byte stream and a preset positive constant is denoted as the first fraction between the two different positions in the session stream's byte stream. The sum of the absolute value of the difference in the order of the two different positions in the byte stream and the number 1 is used as the numerator, and the number of positions in the byte stream is used as the denominator. This fraction is used as the second fraction between the two different positions. The product of the first and second fractions at two different positions in the session stream's byte stream is denoted as the second distance between the two different positions in the session stream's byte stream. The weighted sum of the first and second distances at two different positions in the session stream's byte stream is denoted as the similarity distance between the two different positions in the session stream's byte stream.

[0074] Among them, the use of Skip-gram-based feature embedding algorithm to convert opcodes into opcode vectors, calculate the context co-occurrence distance of different vectors, and perform weighted summation are all well-known techniques and will not be described in detail here; in this embodiment, the preset normal number is set to 0.001; before calculating the second fraction, empty session stream byte streams with a payload length of 0 are filtered out.

[0075] For example, the order of two different positions in a byte stream, such as the 5th position and the 20th position in the byte stream being 7 and 20 respectively.

[0076] During the weighted summation process, the weights of the first distance and the second distance between two different positions in the byte stream of the session stream are 0.7 and 0.3, respectively.

[0077] The first fraction at two different positions in the byte stream of the session stream can make the two larger positions at two different positions in the byte stream of the session stream generate denser field cluster boundaries in subsequent processes.

[0078] The similarity distance between different positions in the byte stream of the session stream is used as the distance between different positions. The DBSCAN clustering algorithm is used to cluster all different positions in the byte stream of the session stream to obtain clusters.

[0079] In this embodiment, the cluster radius is set to 0.25 and the minimum number of neighborhood points is set to 2.

[0080] It is important to understand that the padding bytes or randomized data in the protocol context corresponding to positions that are not clustered into any cluster are actually noise points and do not participate in the subsequent division of byte ranges.

[0081] The intervals that divide the byte stream into the smallest and largest positions within the same cluster are considered as one byte interval.

[0082] In particular, it's important to note that in extreme cases, the DBSCAN clustering algorithm might group bytes with similar values ​​or distances but not adjacent positions into the same cluster. If the byte interval is directly determined by the smallest and largest positions, unrelated fields within the span will be forcibly bundled, causing the field partitioning to fail. Therefore, bytes within the same cluster are sorted by position index. If the position difference between adjacent bytes is greater than 1, the byte interval corresponding to the cluster is split into multiple independent, continuous byte sub-intervals. Each byte sub-interval is treated as an independent field, and the corresponding byte interval is updated using the byte sub-interval.

[0083] The division of byte ranges enables the division of fields. Specifically, each field is represented by a quadruple, meaning it contains four parameters: offset, length, data type, and semantics. The offset is the byte offset of the field's starting position within the byte stream. For example, if the first byte of the field is at position 5 in the byte stream, and the first byte is offset by 4 bytes relative to the field's starting position, then the offset is 4. The length is the byte length of the field. The data type is the field's data format, such as uint8, int16, or string_null_term. The semantics describes the field's role in the protocol, such as checksums or command words.

[0084] Statistical features are extracted from the byte range of the cluster. The specific statistical features of the byte range include: position, length, is_constant, is_numeric, is_printable, is_increasing, and distance_to_end.

[0085] Wherein, position is the field offset; length is the field length in bytes; is_constant is a boolean value indicating whether all byte sequences corresponding to all byte intervals divided by the cluster are completely consistent; is_numeric is a boolean value indicating whether all byte sequences corresponding to all byte intervals divided by the cluster can be parsed as unsigned integers; is_printable is a boolean value indicating whether the proportion of printable ASCII characters (0x20-0x7E) in all byte sequences corresponding to all byte intervals divided by the cluster exceeds 80%; is_increasing is a boolean value, valid only when "is numeric" is true, indicating whether the bytes arranged in message order are strictly monotonically increasing; distance_to_end is an integer value, the distance from the field to the end, calculated as the total number of bytes in the byte stream minus the field offset, used to identify fields located at the end of the message.

[0086] The data type of the field is inferred in descending order of priority. If all conditions of a rule are met, the corresponding type is assigned and subsequent rule checks are stopped. The specific priorities and rules are as follows:

[0087] Priority 1 (string_null_term): "Printable" is true, and the byte sequence ends with 0x00.

[0088] Priority 2 (string_fixed_len): "Is it printable?" is true, and "Is it a constant?" is false.

[0089] Priority 3 (uint16_be / uint16_le): The field length is 2, and "whether it is numeric" is true. The byte order is specified according to the context or common conventions.

[0090] Priority 4 (uint32_be / uint32_le): The field length is 4, and "whether it is numeric" is true. The byte order is specified according to the context or common conventions.

[0091] Priority 5 (ipv4_address): The field length is 4, and the byte value conforms to the common IPv4 address range. In this embodiment, the selected IPv4 address range is the first byte being 192 and 10.

[0092] Priority 6 (raw_bytes): Default type, used when none of the above rules match.

[0093] Based on field characteristics and context, the operational semantics of the field are inferred according to the following rules. Further evaluation stops once a rule is met. The specific rules for inferring the field are as follows:

[0094] 1. Command code: If the field offset is 0, or the field immediately follows the field with the abstract opcode OP_MAGIC_HEADER, and the field length does not exceed 4 bytes, and "Is it numeric?" is true and "Is it constant?" is true, then it is inferred to be a command code.

[0095] 2. Length field: If the field immediately follows the identified command word, the field length is 2 or 4 bytes, and "Is it numeric?" is true, then it is inferred to be a field indicating the length of the subsequent payload.

[0096] 3. Checksum: If the distance from the field to the end is no more than 4 (i.e., it is located at the end of the message), the field length is 2 or 4 bytes, and the "whether it is numeric" is true, then it is inferred to be a checksum.

[0097] 4. Serial number: If "Is it numeric?" is true, "Is it constant?" is false, and "Is it incrementing?" is true, then it is inferred to be a serial number.

[0098] 5. Data payload: If the data type is a string (string_null_term or string_fixed_len), or if it is raw_bytes but its length is directly specified by the preceding length field, then it is inferred to be a data payload.

[0099] 6. Unknown data: If none of the above conditions are met, it is marked as unknown data.

[0100] After extracting statistical features from the fields and inferring the data type and operation semantics, data in fields that are command words, data payloads, or checksums are all considered valid data, while the remaining data are recorded as invalid data.

[0101] To facilitate the understanding of clustering and partitioning fields at all different locations in a byte stream, as well as the extraction of statistical features, data type inference, and operational semantic inference of fields, the following example is provided:

[0102] Suppose a hexadecimal protocol message is 01 02 00 0A 48 65 6C 6C 6F 20 57 6F 72 6C 6400, and the mapped abstract opcode is [OP_CMD, OP_SUBCMD, OP_LEN_HIGH, OP_LEN_LOW, OP_ASCII_CHAR, ...]. The boundary weight calculation results show that positions 0, 2, and 4 have higher weights. Based on this, three clusters are obtained, with corresponding byte ranges of [0,1], [2,3], and [4,14], respectively. The descriptions of each field are generated as follows:

[0103] The first cluster (byte 01 02): extract features such as field offset=0, byte length=2, whether it is constant=true, whether it is numeric=true, match command word rules, and generate field description F=[0,2,uint16_be,command_code].

[0104] The second cluster (byte 00 0A): extracts the features as field offset = 2, byte length = 2, whether it is constant = false, whether it is numeric = true, and combines it with the context of the command word to match the length field rules and generate the field description F = [2, 2, uint16_be, length_field].

[0105] The third cluster (bytes 48 65 6C 6C 6F 20 57 6F 72 6C 64 00): The extracted features are field offset = 4, byte length = 11, printability = true and ending with 0x00, matching the string_null_term type, and the length matches the value of the length field, inferred to be the data payload, and the field description F = [4, 11, string_null_term, data_payload].

[0106] This transforms the byte stream of the session into a structured field description, providing a reliable data reference for parsing and reconstructing unknown protocol content.

[0107] For unknown protocols, feature retrieval tree matching serves as the online processing path: when a data packet does not match the feature retrieval tree and 1D-CNN determines it to be an unknown protocol, the current session stream is copied and sent to the bypass learning module to perform subsequent boundary weight calculations, clustering, and protocol parsing template construction. The generated protocol parsing template is then updated in the feature retrieval tree in memory. Subsequent traffic with the same unknown protocol is directly parsed through the feature retrieval tree.

[0108] Obtain the quadruples of all fields from the byte stream of the session stream. Sort all fields in ascending order according to their offsets to obtain the protocol parsing template. Traverse the protocol parsing template and extract fields whose operation semantics are command words. Use the specific byte values ​​and offsets of these fields in the byte stream of the session stream as the feature fingerprints of the corresponding unknown protocols. If no command word field is identified in the protocol parsing template, the first 4 bytes at a fixed offset position in the message are extracted as the feature fingerprint by default to ensure that the subsequent feature retrieval tree can be built normally.

[0109] If the command word field is not identified in the protocol parsing template, the first 4 bytes at the preset position are extracted as the feature fingerprint; if the actual length of the byte stream is less than 4 bytes, the actual length bytes are extracted and padded with 0x00 to 4 bytes.

[0110] To achieve rapid matching of unknown protocol content, this embodiment constructs a feature retrieval tree for unknown protocols in the memory of the isolation switching module based on the four-tuple description field.

[0111] The feature retrieval tree consists of a root node, internal nodes, and leaf nodes. Each node contains four attributes in memory: byte value, offset, array of child node pointers, and template pointer. The byte value is the eight-bit byte value represented by the node; the offset is the absolute offset of the byte in the network data payload; the array of child node pointers is used to indicate the node branching situation; and the template pointer points to the corresponding protocol parsing template.

[0112] When the isolation switching module detects an unknown protocol, it performs matching according to the following process:

[0113] 1. Extract the first K bytes of the byte stream, where K represents a preset number and K≤16. In this embodiment, the value of K is 4.

[0114] 2. Traverse and search in the feature retrieval tree of the unknown protocol: If the feature fingerprint of the byte stream does not match any protocol parsing template, it means that the unknown protocol is a completely new unknown protocol and needs to be re-clustered to generate new field quadruples and corresponding protocol parsing templates; if the feature fingerprint matches a protocol parsing template, then proceed to the subsequent field parsing process.

[0115] The specific steps of field parsing are as follows: obtain the quadruple description corresponding to the field, slide the pointer to the byte offset position of the field, read the binary data of the corresponding length, and complete the data type conversion according to the data type of the field; store the converted data and the corresponding operation semantics in the protocol parsing table in the form of key-value pairs.

[0116] At this point, the originally disordered and boundless byte stream of the unknown protocol is parsed and restored into structured information objects with clear correspondences, and stored in the protocol parsing table to support protocol restoration.

[0117] This completes the field parsing.

[0118] Step S003: Perform fine-grained field-level checks on the legitimate data to achieve content filtering. Physically isolate and exchange the content-filtered legitimate data to achieve secure exchange of network-isolated data.

[0119] Traditional network gateways, unable to accurately delineate unknown protocol boundaries, can only perform global regular expression matching, easily misinterpreting protocol control commands as sensitive characters, leading to false alarms. This embodiment, based on field parsing results, implements context-based deep content filtering on legitimate data. Specifically, it performs fine-grained field-level checks and executes differentiated checking logic for different operational semantics.

[0120] The specific steps of deep content filtering are as follows:

[0121] 1. When the operation semantics are command words, i.e., when semantics=command_code, compare with the system's preset read and write command whitelist. If an unauthorized high-risk command is found, the session will be blocked. Unauthorized high-risk commands include illegal write operations and formatting commands.

[0122] 2. When the operation semantic is data payload, i.e., when semantic=data_payload, the payload content is scanned for virus signatures and filtered for sensitive keywords using regular expressions. Sensitive keywords include classified information and specific data formats.

[0123] 3. Verify checksum and validity, and filter maliciously tampered messages.

[0124] 4. Combine the protocol session context state to establish a correlation analysis between operational semantics and data dimensions. For example, when the command word indicates "heartbeat detection", the payload should be empty or a fixed very short number of bytes. If an abnormal payload length or executable code is found, it is determined to be a covert channel attack and intercepted.

[0125] Furthermore, legitimate data that has undergone deep content filtering is physically isolated from exchange.

[0126] The captured data packets are stripped of all TCP / IP network layer and transport layer headers and protocol-specific control messages, extracting only the security-verified application layer payload. This payload is then encapsulated into a system-defined, formatted, protocol-free data block. This data block contains only necessary internal routing labels, data length, and checksums, lacking any standard network protocol characteristics, thus fundamentally immunizing against various network layer attacks targeting the TCP / IP protocol stack.

[0127] Internal and external network hosts interact via a private bus or solid-state storage medium: the sending host writes formatted, protocol-free data blocks to the isolation module's storage area, and the receiving host reads the data blocks from the storage area through polling or interrupt mechanisms. This process completely severs the electrical and logical session connections between the internal and external networks. The solid-state storage medium is the isolation switching module.

[0128] This completes the secure exchange of isolated network data.

[0129] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A network isolation data exchange method based on protocol restoration and content filtering, characterized in that, The method includes the following steps: Capture data packets, reassemble the session according to the five-tuples, and obtain the session stream, the corresponding byte stream, and the message byte sequence; Based on the message byte sequence of the session stream, the protocol identification result of the session stream is identified through a neural network. The protocol identification result includes known protocol categories and unknown protocols. The byte values ​​in the byte stream are converted into opcodes according to a preset block length. Combining the differences in byte values ​​at adjacent positions in the byte stream of the session stream, all different positions in the byte stream of the session stream are clustered. The byte intervals are divided according to the clustering results to achieve field partitioning. The fields are represented by quadruples, which include offset, length, data type, and operation semantics. Statistical features are extracted from the fields, and the data type and operation semantics are inferred to identify legal data. Based on the quadruples of all fields partitioned from the byte stream of the session stream, a protocol parsing template and a feature retrieval tree are constructed. The protocol parsing template corresponding to the unknown protocol is re-determined based on the feature retrieval tree. Field parsing is performed on all protocol identification results. Perform fine-grained field-level checks on legitimate data to achieve content filtering, and physically isolate and exchange legitimate data that has passed content filtering to achieve secure exchange of network-isolated data.

2. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The session stream and the byte stream are specifically: Data packets with consistent 5-tuple characteristics among the captured data packets are identified as belonging to the same logical conversation. They are then sorted and deduplicated according to TCP sequence numbers to obtain the session stream and byte stream. The 5-tuple includes the source IP address, destination IP address, transport layer protocol, source port, and destination port.

3. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The specific identification method for the protocol identification result of the session stream is as follows: The message byte sequence of the session stream is truncated and normalized to obtain a tensor of a preset dimension. The tensor is used as the input of the 1D-CNN model to obtain the probability vector of the session stream. The protocol category corresponding to the maximum value in the probability vector that is greater than or equal to the preset protocol recognition threshold is selected as the protocol recognition result of the known protocol category; otherwise, the unknown protocol is selected as the protocol recognition result of the corresponding session stream.

4. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The opcode includes: Bytes 0x00 to 0x0F are mapped to OP_CONST_SMALL, bytes 0xFF and 0xFE are mapped to OP_MAGIC_HEADER, consecutive ASCII character range bytes are mapped to OP_ASCII_CHAR, and bytes that do not match predefined rules are directly mapped to the OP_RAW_BYTE_XX category according to their hexadecimal values.

5. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The method for obtaining the clustering results is as follows: Take any position in the byte stream of the session stream as the center, establish a window of a preset window length, calculate the Shannon entropy of all byte values ​​in the window, and record the absolute value of the difference between any position in the byte stream of the session stream and the byte value of the previous adjacent position as the first-order absolute difference value of that position. The normalized value of the Shannon entropy of the window determined by any position in the byte stream of the session stream and the mean of the normalized value of the first-order absolute difference value of the position are recorded as the boundary weight of the corresponding position. For any opcode in the abstract opcode sequence of the byte stream, the opcode is transformed into an opcode vector using a Skip-gram-based feature embedding algorithm. The context co-occurrence distance between two opcode vectors at different positions in the byte stream of the session stream is denoted as the first distance between the two different positions in the byte stream of the session stream. The second distance between two different positions in the byte stream of the session stream is calculated based on the difference in boundary weights and order in the byte stream. The weighted sum of the first distance and the second distance between two different positions in the byte stream of the session stream is denoted as the similarity distance between the two different positions in the byte stream of the session stream. The similarity distance between different positions in the byte stream of the session stream is used as the distance between different positions. All different positions in the byte stream of the session stream are clustered to obtain clusters.

6. The network isolation data exchange method based on protocol restoration and content filtering according to claim 5, characterized in that, The specific method for calculating the second distance between two different positions in the byte stream of the session stream is as follows: The sum of the mean of the boundary weights at two different positions in the byte stream of the session stream and the preset positive constant is denoted as the first fraction at two different positions in the byte stream of the session stream. The numerator is the sum of the absolute value of the difference between the order of two different positions in the byte stream of the session stream and the number 1, the denominator is the number of positions in the byte stream, and the fraction is the second fraction corresponding to the two different positions. The product of the first and second fractions at two different positions in the byte stream of the session stream is denoted as the second distance between the two different positions in the byte stream of the session stream.

7. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The statistical features extracted from the fields include: The field offset, the field's byte length, whether all byte sequences corresponding to all byte intervals divided by the cluster are completely consistent, whether all byte sequences corresponding to all byte intervals divided by the cluster can be parsed as unsigned integers, whether the proportion of printable ASCII characters in all byte sequences corresponding to all byte intervals divided by the cluster exceeds 80%, whether the numeric bytes arranged in message order are strictly monotonically increasing, and the distance from the end of the field.

8. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The specific methods for constructing the protocol parsing template and feature retrieval tree are as follows: Get the quadruple of all fields from the byte stream of the session stream, sort all fields from the byte stream of the session stream in ascending order according to the field offset, and get the protocol parsing template; The operational semantics of the fields include command words, length fields, checksums, sequence numbers, data payloads, and unknown data. The protocol parsing template is traversed to extract fields whose operational semantics are command words. The specific byte values ​​and offsets of the fields in the byte stream of the session stream are used as the feature fingerprints of the corresponding unknown protocols. If the command word field is not identified in the protocol parsing template, the first 4 bytes at the preset position are extracted as the feature fingerprint; The feature retrieval tree consists of a root node, internal nodes, and leaf nodes. Each node contains four attributes: byte value, offset, array of child node pointers, and template pointer.

9. The network isolation data exchange method based on protocol restoration and content filtering according to claim 1, characterized in that, The specific method for parsing the field is as follows: Get the quadruple corresponding to the field, slide the pointer to the byte offset position of the field, read binary data of the corresponding length, and perform data type conversion according to the data type of the field; The converted data and corresponding operation semantics are stored in the protocol parsing table as key-value pairs.

10. The network isolation data exchange method based on protocol restoration and content filtering according to claim 8, characterized in that, The field-level fine-grained inspection specifically includes: When the operation semantics are command words, they are compared with the preset read and write command whitelist. If an unauthorized high-risk command is found, the session is blocked. When the operation semantics are data payloads, regular expressions are used to scan the payload content for virus signatures and filter sensitive keywords. Verify checksums and their validity, and filter maliciously tampered messages; By combining the protocol session context state, we can establish a correlation analysis between operational semantics and data dimensions.

Images