Traffic data processing method and apparatus, storage medium, and security device

Abstract

The application discloses a kind of flow data processing method, device, storage medium and security equipment. Among them, the method comprises: obtaining the initial flow data between client and server;First protocol information carried in initial flow data is carried out first analysis processing;In the case where the initial flow data after parsing is predetermined function code request, and predetermined function code negotiation passes through, first flow data is carried out first analysis processing in response to the handshake request between client and server;First flow data after parsing is carried out decryption processing;Second protocol information carried in first flow data after decryption is carried out second analysis processing, and second flow data is obtained;In the case where second flow data is normal flow data, encrypted second flow data is sent to server.The present application solves the technical problem that flow encrypted flow data cannot be abnormally identified in the related art.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically, to a method, apparatus, storage medium, and security device for processing traffic data. Background Technology

[0002] A related technology involves an automatic generation and deployment method for industrial firewall policies based on traffic analysis. This method primarily involves an automatic policy learning and configuration module distributing the learned configuration to an intelligent traffic analysis module. The intelligent traffic analysis module then parses the traffic flowing into the industrial firewall based on the configuration entries, stores the parsed metadata, and automatically deploys the multi-dimensional protection policies after a timeout. However, this approach can only parse plaintext traffic. When industrial communication protocols are encrypted using Transport Layer Security (TLS) or Secure Sockets Layer (SSL), it cannot perform parsing, security detection, or defense.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a traffic data processing method, apparatus, storage medium, and security device to at least solve the technical problem in the related art of being unable to identify anomalies in encrypted traffic data.

[0005] According to one aspect of the present invention, a traffic data processing method is provided, comprising: acquiring initial traffic data between a client and a server; performing a first parsing process on first protocol information carried in the initial traffic data to obtain parsed initial traffic data; if it is detected that the parsed initial traffic data is a predetermined function code request, and the client and the server have successfully negotiated the predetermined function code, in response to a handshake request between the client and the server, determining that the first traffic data is encrypted traffic data, performing the first parsing process on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; performing decryption processing on the parsed first traffic data to obtain decrypted first traffic data; performing a second parsing process on second protocol information carried in the decrypted first traffic data to obtain second traffic data; performing a first detection on the second traffic data, and if the obtained first detection result indicates that the second traffic data is normal traffic data, encrypting the second traffic data and sending the encrypted second traffic data to the server.

[0006] According to another aspect of the present invention, a security device is also provided, comprising: a TCP proxy module, a traffic parsing and processing module, an SSL proxy module, and a defense processing module, wherein: the TCP proxy module is used to acquire initial traffic data between a client and a server, and send the initial traffic data to the traffic parsing and processing module; the traffic parsing and processing module is connected to the TCP proxy module, and is used to perform a first parsing process on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data; when it is detected that the parsed initial traffic data is a predetermined function code request, and the predetermined function code negotiation between the client and the server is successful, in response to the handshake request between the client and the server, the first traffic data is determined to be encrypted traffic data, the first parsing process is performed on the first traffic data to obtain parsed first traffic data, and the parsed first traffic data is sent to the SSL proxy module, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; the aforementioned S The SL proxy module, connected to the traffic parsing and processing module, is used to decrypt the parsed first traffic data to obtain decrypted first traffic data, and send the decrypted first traffic data to the traffic parsing and processing module. The traffic parsing and processing module is also used to perform a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data, and send the second traffic data to the defense processing module. The defense processing module, connected to the traffic parsing and processing module, is used to perform a first detection on the second traffic data to obtain a first detection result. The traffic parsing and processing module is also used to send the second traffic data to the SSL proxy module when the first detection result indicates that the second traffic data is normal traffic data. The SSL proxy module is also used to encrypt the second traffic data to obtain encrypted second traffic data, and send the encrypted second traffic data to the TCP proxy module via the traffic parsing and processing module. The TCP proxy module is also used to send the encrypted second traffic data to the server.

[0007] According to another aspect of the present invention, a traffic data processing apparatus is also provided, comprising: an acquisition module for acquiring initial traffic data between a client and a server; a first parsing module for performing a first parsing process on first protocol information carried in the initial traffic data to obtain parsed initial traffic data; a decryption module for, in response to a handshake request between the client and the server, determining that the first traffic data is encrypted traffic data, performing the first parsing process on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; a second parsing module for decrypting the parsed first traffic data to obtain decrypted first traffic data; performing a second parsing process on second protocol information carried in the decrypted first traffic data to obtain second traffic data; and an encryption module for performing a first detection on the second traffic data, and, if the first detection result indicates that the second traffic data is normal traffic data, encrypting the second traffic data and sending the encrypted second traffic data to the server.

[0008] According to another aspect of the present invention, a non-volatile storage medium is also provided, wherein the non-volatile storage medium stores a plurality of instructions, the instructions being adapted to be loaded by a processor and executed any one of the above-described traffic data processing methods.

[0009] In this embodiment of the invention, initial traffic data between the client and the server is obtained; a first parsing process is performed on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data; if the parsed initial traffic data is detected to be a predetermined function code request, and the predetermined function code negotiation between the client and the server is successful, in response to the handshake request between the client and the server, the first traffic data is determined to be encrypted traffic data, and the first parsing process is performed on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; the parsed first traffic data is then processed... The traffic data is decrypted to obtain the first decrypted traffic data; the second protocol information carried in the first decrypted traffic data is parsed to obtain the second traffic data; the second traffic data is subjected to a first detection, and if the first detection result indicates that the second traffic data is normal traffic data, the second traffic data is encrypted and sent to the server. This achieves the purpose of comprehensive detection of the encrypted traffic data, thereby realizing the technical effect of accurately identifying anomalies in the encrypted traffic data and improving the security of traffic data transmission. It also solves the technical problem in related technologies that cannot identify anomalies in encrypted traffic data. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0011] Figure 1 This is a schematic diagram of an S7Comm-Plus protocol message encapsulation structure based on relevant technologies;

[0012] Figure 2 This is a schematic diagram of a traffic data processing method according to an embodiment of the present invention;

[0013] Figure 3 This is a schematic diagram of a safety device according to an embodiment of the present invention;

[0014] Figure 4 This is a schematic diagram of an optional TCP proxy handshake process according to an embodiment of the present invention;

[0015] Figure 5 This is a schematic diagram of an optional SSL handshake process according to an embodiment of the present invention;

[0016] Figure 6 This is a schematic diagram of a traffic data processing device according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, 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. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] First, to facilitate understanding of the embodiments of the present invention, some terms or nouns involved in the present invention will be explained below:

[0020] Ethernet is an open-source, licensed software that allows users to add improvements. Ethereal is compatible with all popular computer systems, including Unix, Linux, and Windows. It can be used to capture and analyze network packets.

[0021] TCP / IP (Transmission Control Protocol / Internet Protocol) refers to a suite of protocols that enables information transmission between multiple different networks.

[0022] SSL / TLS, located at the session layer of the OSI seven-layer model, is used to encrypt communication. SSL (Secure Sockets Layer) is a standard security protocol used to establish an encrypted connection between a web server and a browser in online communication. SSL achieves secure communication between clients and servers through mutual authentication, digital signatures to ensure integrity, and encryption to ensure privacy. TLS (Transport Layer Security) is a protocol designed by the IETF based on SSL 3.0; it is an upgrade to the SSL protocol.

[0023] TPKT, or Application Data Transmission Protocol, is used to transmit application layer data payloads.

[0024] COTP is a protocol defined by the OSI 7-layer protocol layer, located above TCP. It transmits data using "packets" as the basic unit, so that the receiver receives data with the same boundaries as the sender.

[0025] S7Comm-Plus is one of the Siemens S7 communication protocol suites. This layer is related to user data, and the reading of PLC data messages is completed here.

[0026] This paper discusses a method for automatically generating and deploying industrial firewall policies based on traffic analysis. It mainly consists of a policy automatic learning and configuration module, an intelligent traffic analysis module, a timer module, a storage module, a policy generation module, and a policy application module. The automatic learning and configuration module allows configuration of learning duration, learning granularity, protection granularity, and application scenario entries. The intelligent traffic analysis module parses the traffic flowing into the industrial firewall based on the configured entries. The storage module stores the metadata parsed by the traffic analysis module. The timer module triggers the policy generation module to run upon timeout. The policy generation module generates multi-dimensional protection policies and automatically deploys them based on the protection granularity, application scenarios, and metadata in the storage module, using a policy generation algorithm. However, this approach can only parse plaintext traffic. When industrial communication protocols are encrypted using Transport Layer Security (TLS) or Secure Sockets Layer (SSL), it cannot perform parsing, security detection, or defense.

[0027] Industrial systems were not designed with security in mind from the outset. However, as cyberattacks have become increasingly prevalent, industrial systems are now hardening all components and protocols according to relevant regulations. For example, industrial communication protocols undergo authorization, authentication, and encryption, leading to the development of the enhanced S7Comm-Plus protocol with TLS socket layer. This makes it more difficult for malicious attackers to launch low-level attacks (such as replay attacks) remotely. But the battle between offense and defense in the cyber world never ends; where there is encryption, there is decryption, and the more robust the protection, the more sophisticated the cracking methods.

[0028] Currently, industrial firewalls can learn specific elements of the industrial environment by parsing plaintext traffic data to generate industrial protocol whitelists for protection. However, when application layer data of industrial protocols is transmitted after being encrypted with SSL / TLS, the industrial firewall will be unable to properly parse the traffic data to perform whitelisting, blacklisting, and vulnerability protection for industrial protocol traffic. Therefore, industrial firewalls need to obtain plaintext traffic data through SSL proxies for traffic parsing, detection, and protection functions. Furthermore, traditional SSL / TLS sits between the TCP / IP protocol and various application layer protocols, while the S7Comm-Plus protocol is encapsulated on top of TPKT and COTP protocols, and the SSL / TLS layer is also on top of COTP during encryption (the message encapsulation structure is as follows). Figure 1 (As shown). Therefore, traditional SSL proxies are no longer applicable.

[0029] According to an embodiment of the present invention, a method embodiment for processing traffic data is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] Figure 2 This is a flowchart of a traffic data processing method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:

[0031] Step S202: Obtain initial traffic data between the client and the server.

[0032] Optionally, the initial traffic data mentioned above carries the TPKT protocol layer, COTP protocol layer, and S7Comm-Plus protocol layer. The initial traffic data sent from the client to the server is received and intercepted by the TCP proxy module. This is used for subsequent detection of the initial traffic data, and based on the detection results, it determines whether to continue sending subsequent traffic data to the server.

[0033] Step S204: Perform a first parsing process on the first protocol information carried in the initial traffic data to obtain the parsed initial traffic data.

[0034] Optionally, the aforementioned first protocol information includes the TPKT protocol and the COTP protocol. It can be understood that after obtaining the initial traffic data, the protocols (i.e., the TPKT and COTP protocols) at the upper layer of the initial traffic data are parsed, and the parsed traffic data is used to determine the traffic data to be transmitted subsequently.

[0035] Step S206: If the parsed initial traffic data is detected to be a predetermined function code request, and the predetermined function code negotiation between the client and the server is successful, in response to the handshake request between the client and the server, the first traffic data is determined to be encrypted traffic data. If the parsed initial traffic data is detected to be predetermined function code request data, the first traffic data is determined to be encrypted traffic data. The first parsing process is performed on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data. The parsed first traffic data is then decrypted to obtain decrypted first traffic data.

[0036] Optionally, the aforementioned predefined function code request is an initSSL request. Through the above method, if it is confirmed that the initSSL negotiation between the client and server is successful, and the SSL handshake request between the client and server is successful, then the subsequently transmitted traffic data (i.e., the first traffic data) is processed as encrypted traffic data. After performing the first parsing process on the first traffic data to remove the upper-layer TPKT and COTP protocols, the data is decrypted through the SSL proxy module to obtain the decrypted first traffic data.

[0037] In an optional embodiment, when the parsed initial traffic data is detected to be a predetermined function code request, and the predetermined function code negotiation between the client and the server is successful, determining that the first traffic data is encrypted traffic data in response to a handshake request between the client and the server includes: when the parsed initial traffic data is detected to be the predetermined function code request, obtaining the version information of the second protocol information carried in the initial traffic data; and determining whether the client and the server have pre-negotiated the predetermined function code; if the version information of the second protocol information carried in the initial traffic data is a preset first version information, and the predetermined function code negotiation between the client and the server has been successful, determining that the first traffic data is encrypted traffic data in response to a handshake request between the client and the server.

[0038] Optionally, the second protocol information mentioned above is the S7Comm-Plus protocol, and the preset first version information can be, but is not limited to, version V3 of the S7Comm-Plus protocol. The preset function code mentioned above can be, but is not limited to, the function code initSSL. It should be noted that currently only version V3 of the S7Comm-Plus protocol supports SSL encrypted transmission, and both the client and server need to support SSL encryption to perform SSL encrypted transmission. Therefore, the client will send a specific function code initSSL to the server for negotiation confirmation, and after returning a successful response, subsequent messages will begin the SSL handshake and encrypted data transmission.

[0039] By using the above methods, if it is determined that the initial traffic data sent by the client to the server is a predefined function code request (i.e., an SSL proxy request), and the client initiates a specific function code initSSL to the server for negotiation and confirmation, then it is determined that subsequent messages (i.e., the first traffic data) will begin the SSL handshake and encrypted data transmission.

[0040] In an optional embodiment, the method further includes: determining that the first traffic data is unencrypted traffic data if the version information of the second protocol information carried in the initial traffic data is not the preset first version information, or if the client and the server have not negotiated a predetermined function code in advance, or if the client and the server have negotiated a predetermined function code in advance but the negotiation fails; performing a third parsing process on the first traffic data to obtain third traffic data; performing a second detection on the third traffic data to obtain a second detection result; and sending the initial traffic data to the server if the second detection result indicates that the third traffic data is normal traffic data.

[0041] Optionally, a second detection is performed on the third traffic data according to a preset second configuration to obtain a second detection result.

[0042] Optionally, if the S7Comm-Plus version is not V3, or if specific function code negotiation is not performed, or if negotiation fails, the SSL proxy step is skipped, and the first traffic data is directly parsed to obtain the third traffic data (i.e., the parsed S7Comm-Plus traffic data). Security function detection and protection are then performed on the parsed third traffic data. If the detection passes, i.e., the third traffic data is normal traffic data, the transmission of traffic data between the client and the server continues; otherwise, the transmission is blocked, and the client is prohibited from transmitting traffic data to the server.

[0043] Optionally, the aforementioned predefined function code request is an SSL handshake request. It should be noted that if the client's initSSL message receives a successful response, the client's first message will be an SSL handshake request. The traffic parsing and processing module parses the TPKT and COTP protocols and sends the upper-layer data (i.e., the first traffic data) to the SSL proxy module. The SSL proxy module then decrypts the first traffic data to obtain the decrypted first traffic data.

[0044] In an optional embodiment, the method further includes: when it is detected that the first traffic data does not carry a predetermined function code request, performing the third parsing process on the first traffic data to obtain the third traffic data; performing the second detection on the third traffic data to obtain the second detection result; and sending the initial traffic data to the server when the second detection result indicates that the third traffic data is normal traffic data.

[0045] Optionally, a second detection is performed on the third traffic data according to a preset second configuration to obtain a second detection result.

[0046] Optionally, if the first traffic data is found to not carry a predetermined function code request (i.e., an SSL handshake request), the first traffic data is directly parsed, and the third traffic data obtained after parsing is detected according to the preset configuration to determine whether to block or directly allow the transmission of the corresponding traffic data between the client and the server.

[0047] Step S208: Perform a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain the second traffic data.

[0048] Optionally, the second protocol information mentioned above is the S7Comm-Plus protocol. The traffic parsing and processing module performs a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain the required metadata (i.e., the second traffic data) and sends it to the defense processing module for subsequent traffic data anomaly detection.

[0049] Step S210: Perform a first detection on the second traffic data. If the first detection result indicates that the second traffic data is normal traffic data, encrypt the second traffic data and send the encrypted second traffic data to the server.

[0050] Optionally, if the defense processing module detects that the second traffic data is normal traffic data, it will send the second traffic data back to the SSL proxy module for re-encryption, allow the transmission of the corresponding traffic data between the client and the server, and send the encrypted second traffic data to the aforementioned server.

[0051] In one optional embodiment, the first detection of the second traffic data, and the encryption of the second traffic data when the first detection result indicates that the second traffic data is normal traffic data, and the sending of the encrypted second traffic data to the server, includes: performing the first detection on the protocol information carried in the second traffic data based on preset protocol rules to obtain the first detection result; determining that the second traffic data is normal traffic data when the first detection result indicates that the protocol information carried in the second traffic data satisfies the preset protocol rules, encrypting the second traffic data, and sending the encrypted second traffic data to the server.

[0052] Using the above methods and based on preset protocol rules, the protocol information carried in the second traffic data is checked for compliance. This includes determining whether each protocol conforms to preset protocol specifications. If it does, it is considered normal traffic data; otherwise, it is considered abnormal traffic data. If the second traffic data is determined to be normal, it is re-sent to the SSL proxy module for re-encryption, allowing the transmission of the corresponding traffic data between the client and server. The encrypted second traffic data is then sent to the aforementioned server.

[0053] In one optional embodiment, the above-mentioned encryption of the second traffic data when the obtained first detection result indicates that the second traffic data is normal traffic data, and sending the encrypted second traffic data to the server, includes: encrypting the second traffic data when the first detection result indicates that the second traffic data is normal traffic data to obtain the encrypted second traffic data; reassembling the encrypted second traffic data to obtain the reassembled second traffic data; and sending the reassembled second traffic data to the server.

[0054] Optionally, sending the reconstructed second traffic data to the server includes: encapsulating the reconstructed second traffic data on a predetermined protocol layer (COTP and TPKT), and sending the encapsulated second traffic data to the server.

[0055] Optionally, the second traffic data can be re-encrypted via the SSL proxy module. The encrypted second traffic data needs to be sent to the traffic parsing and processing module for reassembly. Since the data content before decryption and after re-encryption will change, the encrypted data needs to be reassembled and encapsulated on COTP and TPKT. The encapsulated second traffic data is then sent to the aforementioned server via the TCP proxy module.

[0056] Optionally, during re-encapsulation, the length information in both the TPKT and COTP layers, as well as the end marker in the COTP layer, need to be modified. After encapsulation, the data is sent to the TCP proxy module, which then sends the encapsulated complete application layer data (i.e., the encapsulated second traffic data) to the server.

[0057] In one optional embodiment, sending the recombined second traffic data to the server includes: obtaining the data volume corresponding to the recombined second traffic data; and, if the data volume is greater than a preset maximum transmission unit, sending the recombined second traffic data in packets to the server.

[0058] Optionally, before transmitting the reassembled second traffic data, it is necessary to determine whether the reassembled second traffic data exceeds the maximum transmission unit (MTU) limit. If it does, the reassembled second traffic data is sent to the aforementioned server in packets.

[0059] Optionally, the execution entity for steps S202 to S210 is a security device comprising a TCP proxy module, a traffic parsing and processing module, an SSL proxy module, and a defense processing module. The TCP proxy module obtains the initial traffic data sent by the client to the server; the traffic parsing and processing module performs a first parsing process on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data; if the parsed initial traffic data is detected to carry a predetermined function code request (i.e., an SSL proxy request), and the handshake between the client and the server is successful, the first traffic data transmitted after the initial traffic data is determined to be processed as encrypted traffic data; the traffic parsing and processing module... The first traffic data carries a first protocol information and undergoes a first parsing process to obtain parsed first traffic data. The SSL proxy module decrypts the parsed first traffic data to obtain decrypted first traffic data. The traffic parsing module performs a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data. The defense processing module performs a first detection on the second traffic data. If the first detection result indicates that the second traffic data is normal traffic data, the SSL proxy module encrypts the second traffic data, and the TCP proxy module sends the encrypted second traffic data to the server.

[0060] Through the above steps S202 to S210, the purpose of comprehensively detecting encrypted traffic data can be achieved, thereby realizing the technical effect of accurately identifying anomalies in encrypted traffic data, improving the security of traffic data transmission, and solving the technical problem in related technologies that cannot identify anomalies in encrypted traffic data.

[0061] According to embodiments of the present invention, a safety device is also provided. Figure 3 This is a schematic diagram of an optional security device according to an embodiment of the present invention, such as... Figure 3 As shown, the aforementioned security equipment includes: a TCP proxy module, a traffic parsing and processing module, an SSL proxy module, and a defense processing module, wherein:

[0062] The aforementioned TCP proxy module is used to obtain the initial traffic data between the client and the server, and send the initial traffic data to the aforementioned traffic parsing and processing module.

[0063] The aforementioned traffic parsing and processing module, connected to the aforementioned TCP proxy module, is used to perform a first parsing process on the first protocol information carried in the aforementioned initial traffic data to obtain parsed initial traffic data; when it is detected that the aforementioned parsed initial traffic data is a predetermined function code request, and the predetermined function code negotiation between the aforementioned client and the aforementioned server is successful, in response to the handshake request between the aforementioned client and the aforementioned server, it determines that the first traffic data is encrypted traffic data, performs the aforementioned first parsing process on the aforementioned first traffic data to obtain parsed first traffic data, and sends the parsed first traffic data to the aforementioned SSL proxy module, wherein the aforementioned first traffic data is encrypted traffic data transmitted after the aforementioned initial traffic data;

[0064] The aforementioned SSL proxy module is connected to the aforementioned traffic parsing and processing module. It is used to decrypt the parsed first traffic data to obtain the decrypted first traffic data and send the decrypted first traffic data to the aforementioned traffic parsing and processing module.

[0065] The aforementioned traffic parsing and processing module is also used to perform a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain the second traffic data, and send the second traffic data to the aforementioned defense processing module.

[0066] The aforementioned defense processing module is connected to the aforementioned traffic parsing processing module and is used to perform a first detection on the aforementioned second traffic data to obtain a first detection result;

[0067] The traffic parsing and processing module is also used to send the second traffic data to the SSL proxy module when the first detection result indicates that the second traffic data is normal traffic data;

[0068] The SSL proxy module is also used to encrypt the second traffic data to obtain encrypted second traffic data, and send the encrypted second traffic data to the TCP proxy module via the traffic parsing and processing module.

[0069] The aforementioned TCP proxy module is also used to send the encrypted second traffic data to the aforementioned server.

[0070] In this embodiment of the invention, the TCP proxy module is configured to acquire initial traffic data between the client and the server, and send the initial traffic data to the traffic parsing and processing module. The traffic parsing and processing module, connected to the TCP proxy module, performs a first parsing process on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data. If the parsed initial traffic data is detected to be a predetermined function code request, and the client and the server have successfully negotiated the predetermined function code, the module responds to the handshake request between the client and the server, determines that the first traffic data is encrypted traffic data, performs the first parsing process on the first traffic data to obtain parsed first traffic data, and sends the parsed first traffic data to the SSL proxy module. The first traffic data is encrypted traffic data transmitted after the initial traffic data. The SSL proxy module, connected to the traffic parsing and processing module, decrypts the parsed first traffic data to obtain decrypted first traffic data, and sends the decrypted first traffic data to the traffic parsing and processing module. The processing module; the traffic parsing processing module is further used to perform a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data, and send the second traffic data to the defense processing module; the defense processing module, connected to the traffic parsing processing module, is used to perform a first detection on the second traffic data to obtain a first detection result; the traffic parsing processing module is further used to send the second traffic data to the SSL proxy module when the first detection result indicates that the second traffic data is normal traffic data; the SSL proxy module is further used to encrypt the second traffic data to obtain encrypted second traffic data, and send the encrypted second traffic data to the TCP proxy module via the traffic parsing processing module; the TCP proxy module is further used to send the encrypted second traffic data to the server, thereby achieving the purpose of comprehensive detection of encrypted traffic data, thus realizing the technical effect of accurately identifying anomalies in encrypted traffic data, improving the security of traffic data transmission, and solving the technical problem in related technologies that it is impossible to identify anomalies in encrypted traffic data.

[0071] Based on the above embodiments and optional embodiments, the present invention proposes an optional implementation method, including a security device comprising a TCP proxy module, a traffic parsing and processing module, an SSL proxy module, and a defense processing module. This security device is used for the interaction of S7Comm-Plus traffic data between the client and the server, obtaining the plaintext content of the traffic, matching blacklists and whitelists, and, according to preset processing actions, either notifying the administrator through log alarms or blocking the corresponding traffic interaction. The traffic parsing and processing module includes two aspects of processing: parsing the three protocols TPKT, COTP, and S7Comm-Plus, and reconstructing TPKT, COTP, and encrypted S7Comm-Plus application layer data. Specifically:

[0072] For the TCP proxy module, the security device's TCP proxy operates in full proxy mode, implementing all functions of the TCP protocol stack, including out-of-order reordering, retransmission, sliding window, and congestion control. The TCP handshake in full proxy mode is as follows: Figure 4 As shown, when the client (i.e., the sender) initiates a connection request, it first completes a TCP three-way handshake with the security device (i.e., the proxy), and then the security device completes a TCP three-way handshake connection with the server (i.e., the receiver).

[0073] For the protocol parsing part of the traffic parsing and processing module, the application layer data (i.e., the initial traffic data) obtained after the TCP proxy is sent to the traffic parsing and processing module. This data part is as follows: Figure 1This includes TPKT, COTP, S7Comm-Plus protocol layers, or encrypted S7Comm-Plus data. It's important to note that security devices do not perform full TCP proxying on all traffic; only traffic meeting preset configurations and matching certain characteristics is fully proxied to avoid impacting the device's traffic forwarding performance. After completing the TCP three-way handshake, a two-way COTP handshake is required before S7Comm-Plus data transmission. Currently, only S7Comm-Plus version V3 supports SSL encrypted transmission, and both the client and server must support SSL encryption. Therefore, the client initiates a specific function code `initSSL` to the server for negotiation and confirmation. After a successful response, subsequent packets begin the SSL handshake and encrypted data transmission. If the S7Comm-Plus version is not V3, or if specific function code negotiation is not performed, or if negotiation fails, the initial traffic data is determined to be unencrypted, skipping the SSL proxy step and directly performing security function checks and protection on the parsed S7Comm-Plus traffic data. If the client's initSSL message receives a successful response, the client's first message will be an SSL handshake request. The traffic parsing and processing module parses the TPKT and COTP protocols and sends the upper-layer data (i.e., the first traffic data) to the SSL proxy module. If it is not an SSL handshake request, the initial traffic data is treated as unencrypted traffic data for subsequent processing, blocking or allowing the corresponding traffic according to the configuration. Subsequent interactive traffic, including the COTP upper-layer SSL encrypted data (i.e., the first traffic data), will also be sent to the SSL proxy module for decryption. The decrypted first traffic data is then sent to the traffic parsing and processing module for S7Comm-Plus protocol parsing to obtain the necessary metadata (i.e., the second traffic data) and send it to the defense processing module. If the defense processing module detects that the second traffic data is normal, it sends the second traffic data back to the SSL proxy module for re-encryption. The encrypted data is then sent back to the traffic parsing and processing module for reassembly. Both the unencrypted traffic data and the parsed metadata will undergo compliance checks. If they do not comply with the specifications, corresponding actions will be taken according to the preset configuration, i.e., blocking or allowing the transmission of the corresponding traffic data between the client and the server.

[0074] For the packet reassembly part of the traffic parsing and processing module, the second traffic data is re-encrypted through the SSL proxy module. The encrypted second traffic data needs to be sent back to the traffic parsing and processing module for reassembly. Because the data content before decryption and after re-encryption will change, the encrypted data needs to be reassembled and encapsulated on COTP and TPKT. The encapsulated second traffic data is then sent to the aforementioned server via the PCT proxy module. During recapsulation, the length information in the TPKT and COTP layers, as well as the end marker in the COTP layer, need to be modified respectively. After encapsulation, it is sent to the TCP proxy module, which sends the encapsulated complete application layer data (i.e., the encapsulated second traffic data) to the server. If the reassembled second traffic data is determined to exceed the Maximum Transmission Unit (MTU) limit during reassembly, it is sent in packets.

[0075] For the SSL proxy module, this module performs proxying based on the standard SSL handshake process, and the overall proxy process... Figure 5 As shown, the SSL proxy function replaces the encryption server's digital certificate with an SSL proxy certificate and sends the SSL proxy certificate to the client. During this process, the security device establishes SSL connections with both the actual server and client, acting as both an SSL client and an SSL server, thereby obtaining the plaintext content of the encrypted communication. The SSL proxy certificate is generated by re-signing the server certificate using the security device's own certificate. For servers that do not require SSL proxying, the corresponding IP address can be configured to be added to the allow list, and traffic will be directly allowed. For servers that require SSL proxying, the device will check the parameters during the SSL negotiation process. For SSL negotiation parameters that meet the check criteria, traffic can be blocked or allowed. Traffic set to block will be blocked; traffic set to allow will not be decrypted. Simultaneously, dynamically adding this IP address to the allow list will allow its traffic; traffic that is neither blocked nor allowed will be decrypted.

[0076] For the defense processing module, after decrypting the plaintext content, it performs blacklist and whitelist filtering and vulnerability detection. If the content does not conform to the whitelist, hits the blacklist, or has a corresponding vulnerability, the network device will allow, block, or reset the TCP connection according to preset settings. It can also notify the administrator of relevant threats via email, SMS, etc., according to preset settings, so that appropriate action can be taken. In other words, the defense processing module performs compliance checks on both unencrypted traffic data and the parsed metadata. If it does not comply with regulations, it will take corresponding actions according to preset configurations, such as blocking or directly allowing the transmission of corresponding traffic data between the client and the server.

[0077] This invention provides protection for both encrypted and unencrypted S7Comm-Plus protocols, offering more comprehensive protection and a wider range of applications. It provides a general method for obtaining plaintext content from SSL encrypted traffic over COTP. Based on the S7Comm-Plus traffic interaction, it determines whether SSL proxying is necessary. The decrypted plaintext content undergoes compliance checks, filtering out abnormal packets. SSL negotiation parameters are checked, anomalies are filtered, and trusted traffic is allowed, thereby achieving comprehensive inspection of transmitted traffic data and improving the security of traffic data transmission.

[0078] This embodiment also provides a traffic data processing device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the terms "module" and "device" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0079] According to an embodiment of the present invention, an apparatus embodiment for implementing the above-described traffic data processing method is also provided. Figure 6 This is a schematic diagram of the structure of a traffic data processing device according to an embodiment of the present invention, as shown below. Figure 6 As shown, the aforementioned traffic data processing device includes: an acquisition module 600, a first parsing module 602, a decryption module 604, a second parsing module 606, and a decryption module 608, wherein:

[0080] The aforementioned acquisition module 600 is used to acquire initial traffic data between the client and the server;

[0081] The first parsing module 602 is connected to the acquisition module 600 and is used to perform a first parsing process on the first protocol information carried in the initial traffic data to obtain the parsed initial traffic data.

[0082] The decryption module 604, connected to the first parsing module 602, is used to, in response to the handshake request between the client and the server, determine that the first traffic data is encrypted traffic data, and perform the first parsing process on the first traffic data to obtain the parsed first traffic data when it is detected that the parsed initial traffic data is a predetermined function code request and the predetermined function code negotiation between the client and the server is successful. The first traffic data is encrypted traffic data transmitted after the initial traffic data.

[0083] The second parsing module 606 is connected to the decryption module 604 and is used to decrypt the parsed first traffic data to obtain decrypted first traffic data; and to perform a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data.

[0084] The encryption module 608 is connected to the second parsing module 606 and is used to perform a first detection on the second traffic data. If the first detection result indicates that the second traffic data is normal traffic data, the encryption module 608 encrypts the second traffic data and sends the encrypted second traffic data to the server.

[0085] In this embodiment of the invention, the acquisition module 600 is used to acquire initial traffic data between the client and the server; the first parsing module 602, connected to the acquisition module 600, is used to perform a first parsing process on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data; the decryption module 604, connected to the first parsing module 602, is used to, in response to the handshake request between the client and the server, determine that the first traffic data is encrypted traffic data, and perform the first parsing process on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; the second... The parsing module 606, connected to the decryption module 604, is used to decrypt the parsed first traffic data to obtain decrypted first traffic data; and to perform a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data. The encryption module 608, connected to the second parsing module 606, is used to perform a first detection on the second traffic data. If the obtained first detection result indicates that the second traffic data is normal traffic data, the second traffic data is encrypted, and the encrypted second traffic data is sent to the server. This achieves the purpose of comprehensive detection of the encrypted traffic data, thereby realizing the technical effect of accurately identifying anomalies in the encrypted traffic data and improving the security of traffic data transmission. It also solves the technical problem in related technologies that it is impossible to identify anomalies in encrypted traffic data.

[0086] Optionally, the above apparatus further includes: a first acquisition unit, configured to acquire version information of the second protocol information carried in the initial traffic data; and to determine whether the client and the server have pre-negotiated a predetermined function code; and a first determination unit, configured to determine that the handshake between the client and the server is successful if the version information of the second protocol information carried in the initial traffic data is a preset first version information, and the client and the server have pre-negotiated a predetermined function code and the negotiation is successful.

[0087] Optionally, the above apparatus further includes: a first parsing unit, configured to determine that the first traffic data is unencrypted traffic data if the version information of the second protocol information carried in the initial traffic data is not the preset first version information, or if the client and the server have not negotiated a predetermined function code in advance, or if the client and the server have negotiated a predetermined function code in advance but the negotiation fails; perform a third parsing process on the first traffic data to obtain third traffic data; a first detection unit, configured to perform a second detection on the third traffic data to obtain a second detection result; and a first sending unit, configured to send the initial traffic data to the server if the second detection result indicates that the third traffic data is normal traffic data.

[0088] Optionally, the above apparatus further includes: a second parsing unit, configured to perform the third parsing process on the first traffic data to obtain the third traffic data when the first traffic data is detected to not carry a predetermined function code request; a second detection unit, configured to perform the second detection on the third traffic data to obtain the second detection result; and a second sending unit, configured to send the initial traffic data to the server when the second detection result indicates that the third traffic data is normal traffic data.

[0089] Optionally, the encryption module includes: a third detection unit, configured to perform the first detection on the protocol information carried in the second traffic data based on preset protocol rules, and obtain the first detection result; and a first encryption unit, configured to determine that the second traffic data is normal traffic data when the first detection result indicates that the protocol information carried in the second traffic data meets the preset protocol rules, and to encrypt the second traffic data and send the encrypted second traffic data to the server.

[0090] Optionally, the encryption module further includes: a second encryption unit, configured to encrypt the second traffic data when the first detection result indicates that the second traffic data is normal traffic data, to obtain the encrypted second traffic data; a message reassembly unit, configured to reassemble the encrypted second traffic data to obtain the reassembled second traffic data; and a third sending unit, configured to send the reassembled second traffic data to the server.

[0091] Optionally, the third sending unit includes: a first acquisition subunit, used to acquire the data volume corresponding to the reconstructed second traffic data; and a first sending subunit, used to send the reconstructed second traffic data to the server in packets when the data volume exceeds a preset maximum transmission unit. It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or, the above modules can be located in different processors in any combination.

[0092] It should be noted that the acquisition module 600, the first parsing module 602, the decryption module 604, the second parsing module 606, and the decryption module 608 mentioned above correspond to steps S202 to S210 in the embodiments. The instances and application scenarios implemented by the above modules and their corresponding steps are the same, but they are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can run on a computer terminal.

[0093] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0094] The aforementioned traffic data processing device may further include a processor and a memory. The aforementioned acquisition module 600, first parsing module 602, decryption module 604, second parsing module 606, decryption module 608, etc., are all stored in the memory as program modules, and the processor executes the aforementioned program modules stored in the memory to realize the corresponding functions.

[0095] The processor contains a core that retrieves the corresponding program modules from memory. One or more cores may be configured. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0096] According to an embodiment of this application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute any of the aforementioned traffic data processing methods.

[0097] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals, and the non-volatile storage medium includes stored programs.

[0098] Optionally, during program execution, the device containing the non-volatile storage medium performs the following functions: acquiring initial traffic data between the client and the server; performing a first parsing process on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data; if the parsed initial traffic data is detected to be a predetermined function code request and the handshake between the client and the server is successful, determining that the first traffic data is encrypted traffic data, performing the first parsing process on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; decrypting the parsed first traffic data to obtain decrypted first traffic data; performing a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data; performing a first detection on the second traffic data, and if the first detection result indicates that the second traffic data is normal traffic data, encrypting the second traffic data and sending the encrypted second traffic data to the server.

[0099] According to an embodiment of this application, an embodiment of a processor is also provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes any of the above-described traffic data processing methods during runtime.

[0100] According to an embodiment of this application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is adapted to execute a program that initializes the traffic data processing method steps described above.

[0101] Optionally, when the aforementioned computer program product is executed on a data processing device, it is suitable to execute an initialization program comprising the following steps: acquiring initial traffic data between a client and a server; performing a first parsing process on the first protocol information carried in the initial traffic data to obtain parsed initial traffic data; if it is detected that the parsed initial traffic data is a predetermined function code request and the handshake between the client and the server is successful, determining that the first traffic data is encrypted traffic data, performing the first parsing process on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; decrypting the parsed first traffic data to obtain decrypted first traffic data; performing a second parsing process on the second protocol information carried in the decrypted first traffic data to obtain second traffic data; performing a first detection on the second traffic data, and if the obtained first detection result indicates that the second traffic data is normal traffic data, encrypting the second traffic data and sending the encrypted second traffic data to the server.

[0102] This invention provides an electronic device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: acquiring initial traffic data between a client and a server; performing a first parsing process on first protocol information carried in the initial traffic data to obtain parsed initial traffic data; if the parsed initial traffic data is detected to be a predetermined function code request, and the handshake between the client and the server is successful, determining that the first traffic data is encrypted traffic data, performing the first parsing process on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data; decrypting the parsed first traffic data to obtain decrypted first traffic data; performing a second parsing process on second protocol information carried in the decrypted first traffic data to obtain second traffic data; performing a first detection on the second traffic data; if the first detection result indicates that the second traffic data is normal traffic data, encrypting the second traffic data and sending the encrypted second traffic data to the server.

[0103] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0104] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of modules described above can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between modules, and may be electrical or other forms.

[0106] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0107] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0108] If the aforementioned integrated modules are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a non-volatile storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned non-volatile storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0109] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A traffic data processing method characterized by, The method comprises: acquiring initial traffic data between a client and a server, wherein the initial traffic data carries a TPKT protocol layer, a COTP protocol layer, and an S7Comm-Plus protocol layer; performing first parsing processing on first protocol information carried in the initial traffic data to obtain parsed initial traffic data, wherein the first protocol information comprises a TPKT protocol and a COTP protocol; in a case where it is detected that the parsed initial traffic data is a predetermined function code request and predetermined function code negotiation between the client and the server is passed, determining, in response to a handshake request between the client and the server, that first traffic data is encrypted traffic data, performing the first parsing processing on the first traffic data to obtain parsed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data, the predetermined function code request is an initSSL request, and the first parsing processing is parsing a TPKT protocol and a COTP protocol in an upper layer of the first traffic data; performing decryption processing on the parsed first traffic data to obtain decrypted first traffic data; performing second parsing processing on second protocol information carried in the decrypted first traffic data to obtain second traffic data, wherein the second protocol information is an S7Comm-Plus protocol; performing first detection on the second traffic data, and in a case where a first detection result acquired indicates that the second traffic data is normal traffic data, performing encryption processing on the second traffic data and sending encrypted second traffic data to the server.

2. The method of claim 1, wherein, The method further comprises: in a case where it is detected that the parsed initial traffic data is the predetermined function code request, acquiring version information of the second protocol information carried in the initial traffic data; and determining whether predetermined function code negotiation between the client and the server is performed in advance; in a case where the version information of the second protocol information carried in the initial traffic data is preset first version information, predetermined function code negotiation between the client and the server is performed in advance, and the negotiation is passed, determining, in response to a handshake request between the client and the server, that the first traffic data is encrypted traffic data, wherein the preset first version information is a V3 version of an S7Comm-Plus protocol.

3. The method of claim 2, wherein, The method further comprises: In a case that version information of the second protocol information carried in the initial traffic data is not the preset first version information, or the predetermined function code is not previously negotiated between the client and the server, or the predetermined function code is previously negotiated between the client and the server but negotiation fails, it is determined that the first traffic data is unencrypted traffic data; performing third parsing processing on the first traffic data to obtain third traffic data, wherein the third traffic data is parsed S7Comm-Plus traffic data; performing second detection on the third traffic data to obtain a second detection result; in a case that the second detection result indicates that the third traffic data is normal traffic data, sending the initial traffic data to the server.

4. The method of claim 3, wherein, The method further comprises: in a case that it is detected that the first traffic data does not carry the predetermined function code request, performing the third parsing processing on the first traffic data to obtain the third traffic data; performing the second detection on the third traffic data to obtain the second detection result; in a case that the second detection result indicates that the third traffic data is normal traffic data, sending the initial traffic data to the server.

5. The method of claim 1, wherein, The first detection on the second traffic data, in a case that the obtained first detection result indicates that the second traffic data is normal traffic data, comprises: performing the first detection on protocol information carried in the second traffic data based on a preset protocol rule to obtain the first detection result; in a case that the first detection result indicates that the protocol information carried in the second traffic data satisfies the preset protocol rule, determining that the second traffic data is normal traffic data, performing encryption processing on the second traffic data, and sending the encrypted second traffic data to the server.

6. The method according to any one of claims 1 to 5, characterized in that, The first detection on the second traffic data, in a case that the obtained first detection result indicates that the second traffic data is normal traffic data, comprises: in a case that the first detection result indicates that the second traffic data is normal traffic data, performing encryption processing on the second traffic data to obtain the encrypted second traffic data; performing packet recombination on the encrypted second traffic data to obtain recombined second traffic data; sending the recombined second traffic data to the server; The sending of the recombined second traffic data to the server comprises: encapsulating the recombined second traffic data in a predetermined protocol layer and sending the encapsulated second traffic data to the server.

7. The method of claim 6, wherein, The sending of the recombined second traffic data to the server comprises: obtaining a data amount corresponding to the recombined second traffic data; in a case that the data amount is greater than a preset maximum transmission unit, packetizing the recombined second traffic data and sending the packetized second traffic data to the server.

8. A security device characterized in that, The security device comprises a TCP proxy module, a traffic analysis processing module, an SSL proxy module, and a defense processing module, wherein: The TCP proxy module is configured to obtain initial traffic data between a client and a server, and send the initial traffic data to the traffic analysis processing module, wherein the initial traffic data carries a TPKT protocol layer, a COTP protocol layer, and a S7Comm-Plus protocol layer. The traffic analysis processing module is connected to the TCP proxy module and configured to perform first analysis processing on first protocol information carried in the initial traffic data to obtain analyzed initial traffic data; in a case where it is detected that the analyzed initial traffic data is a predetermined function code request and predetermined function code negotiation between the client and the server is passed, the traffic analysis processing module is configured to determine that first traffic data is encrypted traffic data in response to a handshake request between the client and the server, perform the first analysis processing on the first traffic data to obtain analyzed first traffic data, and send the analyzed first traffic data to the SSL proxy module, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data, the first protocol information comprises a TPKT protocol and a COTP protocol, the predetermined function code request is a function code initSSL request, and the first analysis processing is analysis of the TPKT protocol and the COTP protocol in an upper layer of the first traffic data. The SSL proxy module is connected to the traffic analysis processing module and configured to perform decryption processing on the analyzed first traffic data to obtain decrypted first traffic data, and send the decrypted first traffic data to the traffic analysis processing module. The traffic analysis processing module is further configured to perform second analysis processing on second protocol information carried in the decrypted first traffic data to obtain second traffic data, and send the second traffic data to the defense processing module, wherein the second protocol information is a S7Comm-Plus protocol. The defense processing module is connected to the traffic analysis processing module and configured to perform first detection on the second traffic data to obtain a first detection result. The traffic analysis processing module is further configured to send the second traffic data to the SSL proxy module in a case where the first detection result indicates that the second traffic data is normal traffic data. The SSL proxy module is further configured to perform encryption processing on the second traffic data to obtain encrypted second traffic data, and send the encrypted second traffic data to the TCP proxy module via the traffic analysis processing module. The TCP proxy module is further configured to send the encrypted second traffic data to the server.

9. A traffic data processing apparatus characterized by comprising: The security device comprises: an obtaining module configured to obtain initial traffic data between a client and a server, wherein the initial traffic data carries a TPKT protocol layer, a COTP protocol layer, and a S7Comm-Plus protocol layer. The first analysis module is configured to perform first analysis processing on first protocol information carried in the initial traffic data, to obtain analyzed initial traffic data, wherein the first protocol information includes TPKT protocol and COTP protocol. The decryption module is configured to, in a case where it is detected that the analyzed initial traffic data is a predetermined function code request and a predetermined function code negotiation between the client and the server is passed, determine, in response to a handshake request between the client and the server, that first traffic data is encrypted traffic data, perform the first analysis processing on the first traffic data, and obtain analyzed first traffic data, wherein the first traffic data is encrypted traffic data transmitted after the initial traffic data, the predetermined function code request is an initSSL request, and the first analysis processing is analysis of TPKT protocol and COTP protocol in an upper layer of the first traffic data. The second analysis module is configured to perform decryption processing on the analyzed first traffic data, to obtain decrypted first traffic data, and perform second analysis processing on second protocol information carried in the decrypted first traffic data, to obtain second traffic data, wherein the second protocol information is S7Comm-Plus protocol. The encryption module is configured to perform first detection on the second traffic data, and in a case where a first detection result obtained indicates that the second traffic data is normal traffic data, perform encryption processing on the second traffic data, and send encrypted second traffic data to the server.

10. A non-volatile storage medium, comprising: The non-volatile storage medium stores a plurality of instructions, and the instructions are adapted to be loaded and executed by the processor to perform the traffic data processing method in any one of claims 1 to 7.

Images